At first, I was planning to write about the top mistakes that novice Scrum/agile teams make. But then I wanted to say it in a positive way. So, I ended up writing about the top three improvements new Scrum/agile teams can make. Here it goes.
Focus on Stories, Not Tasks
Focus on stories (or features), and not tasks. Yes, team members still need to pull tasks from the board, and perform them. But don't forget that the team's goal is to complete stories. This means that when a team member has an option to pull a task from the board, the task should be part of the current on-going story. It would be better if team members are discouraged from starting a task that is not part of the current on-going story.
I've seen the following board (see below) several times in my few years of agile. Each story is grouped as a row (left to right) on the board. Notice how the team has completed several tasks, but none of the stories are done.
| To Do | In Progress | Done |
|---|---|---|
|
Task A8
|
Task A6
Task A3
Task A5
|
Task A1
Task A2
Task A4
Task A7
|
|
Task B8
Task B6
|
Task B3
Task B7
|
Task B1
Task B2
Task B4
Task B5
|
To put this in the positive, the team is encouraged to achieve a board that looks more like this (below). Here, team members are encouraged to stay on tasks with the on-going story (or feature) until it is done. They're discouraged from starting tasks on another story. But this doesn't mean that team members become idle. They're asked to help other team members to get the story done.
| To Do | In Progress | Done |
|---|---|---|
|
Task A8
Task A6
Task A3
|
Task A5
Task A1
Task A2
Task A4
Task A7
|
|
|
Task B8
Task B6
Task B3
Task B7
Task B1
Task B2
Task B4
Task B5
|
Start Only with Ready Stories
I find that only a few agile teams have heard of definition of ready (DoR). Most of them have heard of definition of done (DoD), but not DoR. I've seen teams start sprints with stories that are far from being ready.
Some organizations (or companies) provide a checklist to get stories ready (not just sort of ready). I've seen the checklist include items like: estimated at the right size, prioritized by business value, has "done" criteria. It's difficult (almost impossible) to get a user story (or feature) done, if the team does not have an agreed "done" criteria. This "done" criteria (or acceptance criteria) is usually set before the story can be included in a sprint (as part of backlog refinement).
So, other than DoD, take a look at DoR. It might just help you and your team improve its productivity.
Split Stories to Fit in Sprint
Sometimes, user stories (or features) are too big to fit in a sprint (or iteration). When this happens, it would be better to split the user story, than to extend the sprint (to make it long enough for the team to complete the story).
I've witnessed teams extending their sprint cycles just to accommodate larger stories (or epics). And that's probably because they have limited skills in splitting stories. Many new agile teams attempt to split stories by architectural layers: one story for the UI, another for the database, etc. This results into stories that are not valuable to a user, and become interdependent with each other.
So, do be careful when splitting stories. Following Bill Wake's INVEST model for good user stories is highly recommended. You can refer to Richard Lawrence's Patterns for Splitting User Stories.
Conclusion
The above points may not apply to all teams. But if it does, please let me know. I would love to hear your (or your team's) experiences.
Here's wishing you more success in achieving your team's goals!
