In my last article, I talked about “story walls” but in fact, I focused on task walls. The difference is minor but choosing one over the other can help improve collaboration among the team.
Task walls, predictably, are about tasks – “today I will do task 1” while story walls focus on the thing being built – “today I am working on story 3.”
The starting point is the same for either version – the team get together and agree on what they will work on next. Assuming the team are working in iterations (sprints), then the team will commit to what they hope to achieve by the end of the iteration.
The team put the stories they want to commit to doing in the “ready” column. But rather than breaking the story into individual tasks, the team track the evolution of the story from “ready to start” through to “done.”
The columns in a story wall represent the points where something changes and the team want to keep track of the status of the story.
In my example, the team will “scope” a story, write some code, test it and then claim it is done. For really simple work, though, it could be enough to just have “ready” and “done,” as we saw in the previous article:
We can see progress as stories move across from left to right. Here we see that someone has started scoping story one, but nothing else has happened.
Then as work progresses, team members take another story from “ready” and get started, or they move stories to “code” and “test” as the work continues.
Then as work progresses, team members take another story from “ready” and get started, or they move stories to “code” and “test” as the work continues.The argument for stories
The argument for tracking stories rather than tasks
Tracking the story, without tracking tasks, has some benefits:
- Some work is not task-based. So it is not the completion of the tasks that is relevant but rather the “creative process” of pondering, playing and then reviewing something. In this situation, it is often better to agree on a standard that the work will meet. For example, a writer agrees that he will have “first draft ready” and an editor agrees that she will have “first review complete” before presenting the work in the walkthrough with the team. Both author and editor work together throughout but they do not detail the tasks that they will complete as part of their work.
- Some work is not collaborative at the task level. Although collaboration is core to agile, some work is really done by specialists who do not care how the other boffins work their magic. For example, a developer might write code, but then a specialist security tester and a specialist accessibility tester might run their tests. Each knows the other is great at their job and supports the other, but the work is relatively independent. Breaking work into individual tasks and then reporting on them feels like the team is micromanaging each other rather than managing the work as a team.
- Prioritization and innovation might improve if teams can break stories into components that create value or test a hypothesis on their own. Breaking the story down with acceptance tests or goals can help keep the team focused on value rather than activity.
- Some teams are already mature and have their mojo. They agree what work they are going to do and break it into pieces (stories) but the tasks are predictable, or the people move through them so swiftly, that tracking the tasks adds no value.
- It is easier to see bottlenecks, as shown below.
Seeing the bottleneck clearly
Here is a team that has a bottleneck halfway through the iteration. You don’t need to be an agile coach to predict that the bottleneck appears to be in testing. Maybe the team should stop throwing work at the tester and help with testing, or maybe developers are creating a lot of bugs. Either way, it is worth investigating.
Interestingly, someone in the team notes that the bottleneck was in coding for half the iteration and has only appeared in testing near the end of the iteration. Someone else notes that this seems to happen a lot.
The team discusses the seemingly sensible idea of having a coding freeze each iteration when one of the team suddenly grasps at her chest, prances about with a lot of drama and falls down on her back.
The team falls silent and hears her say “This is high-speed waterfall, not agile. I want to be in an agile team. One that collaborates and learns as it works.”
The team looks at the way the story wall appears during the first week of the iteration and compares it to the typical picture in the second week:
It appears that stories take a long time to scope, then fly through coding and crash into the tester like a tsunami at the beginning of week two.
The team tries breaking the stories down differently. They break each story into “must have” and “nice to have” components using MOSCOW. Now they complete a must-have mini-story then test it and go back to code more. There is some rework as they code the same story a couple of times but it increases learning and flexibility. It even seems to help with scoping the story when they build a little before finalizing their analysis of the story
Importantly the change also increases the speed and quality of testing so the team members are all pretty happy.
The argument for tracking tasks
Breaking stories into tasks and tracking work at that level has some benefits:
- Teams often claim their work is independent, but when the team starts to break work down into tasks they often see connections and improvements that were not visible before. For example, an editor might discover that an author creates a whole background for each character in a story, even though a lot of the information does not make it to the story itself. The editor then says that she can use this info to give better insights and comments on the story, rather than just looking at the first draft.
- Breaking work into tasks will focus people on what actually has to be done in order to get through the work. This can improve planning and highlight gaps and issues early.
- People sometimes say that breaking work into tasks means that the team is getting too detailed. But in fact, the team does not have to work out every tiny step. They are free to plan at the level that makes sense to them, perhaps even breaking some tasks into more detail during the iteration.
- Some teams prefer to have a stand-up where each person says what they are actually doing that day, rather than just what story or problem they are working on. But if the story wall does not have tasks then this can get confusing, with people sometimes discussing the tasks they are doing and forgetting that they need to progress the stories each day.
- It is easier to create a burn-down chart and the know when things are slipping if you see them slipping one task at a time. A burn-down chart based on stories instead of tasks can look like a flat line with a sudden drop and then another flat line. (Note that the counter argument is that if a burn-down chart looks like a set of steps then this might mean work is being managed in large chunks and the team should break things down more).
- It is easy to say when a story is “done” if the team know all the tasks that need to be completed in order for it to be done.
Additional considerations if you are not using tasks
There is no best practice here. Some teams like to use tasks and others like to track work as stories.
But if you do not use tasks then it is worth considering a couple of points.
Successful is not measured in the volume of stories or features produced
In most agile teams, defining “Done” is important. When using tasks, some of the tasks will include checking the quality of the work or gathering feedback. This information can be lost if the team simply agree how to test the functionality of each story rather than defining goals for the iteration and successful implementation of stories.
It is important to define “done” for the sprint as “the conditions to be met in order to know that the work done has added value and met our expectation of quality”. This generally involves valuable work that is not attributed to any one story – for example running things through a focus group, regression testing, performance testing, roll-back testing, taking the time to understand experimental results and many other things.
If the team measure velocity then they need to understand that a lot of work will not be at the individual story level. In fact, many of my teams spend half their time working on “non-stories.” This is fine as long as the team understands that velocity is a tool to help them with planning and the team members are not a bunch of tools to maximize the velocity that can be reported to management or the dark overlords.
Defects and surprises need to be managed somehow
If a team is using tasks and a defect appears, then it is just another task to complete before the work is done.
Similarly, if something unexpected happens or the team agrees to make some changes based on what they discussed in the retrospective, then the team can create new tasks.
But if the team is not tracking tasks then this is not the case. So there is a temptation to focus on story completion by deferring (or ignoring) defects, potential opportunities, and other things.
Some teams treat defects and retro ideas as new stories. They also use “spikes” or a similar term to track research, risk mitigation, and experiments.
Others allocate defects to stories. It doesn’t matter as long as the team manages the creation of value rather than the completion of stories.
Defining “ready” becomes an issue
Naughty teams sometimes assume that every story is perfectly understood before they are expected to start work on it. This quickly becomes apparent when the team starts breaking things into tasks since people literally say they can’t complete their task until something else has happened.
Teams that do not use tasks often define “ready” as “we start here.” In some naughty teams who love waterfall and love making others do lot’s of work, the definition of ready reads like a contractual agreement that someone else must completely define the story before any work begins. But since most of the work in some teams is creating understanding rather than executing according to spec, this leads to trouble.
A common solution is to define the minimum that needs to be done as a starting point and then agree that this is where “the team” start work.
Some teams use the iteration planning session to discuss each story and agree to how it will be analyzed and broken down in the iteration. Others prefer to separate the planning and the discussion of breaking the work down.
If you are not breaking the work down in the iteration planning meeting then you will usually benefit from having a regular “break stuff down in more detail” meeting. This might be called backlog grooming, backlog refinement or story elaboration.
For some hints on doing this, you can look at these articles:
- Story collaboration sessions
- The mechanical BA
- Using regression testing for requirement generation
- Breaking things down based on common errors
Not all story walls track stories
I have been using the term “story” throughout this article. But a story wall tracks “stuff” and I am therefore using the term story very liberally.
For example, here is a “story card” used by some design thinkers. But it is not a feature or a user story, it is a test to evaluate a hypothesis or assumption:
These are often tracked on a “progress board” that is really just a story wall as we have discussed it here:
http://blog.strategyzer.com/posts/2015/3/11/lean-startup-progress-board
Good luck
Hopefully, you can see that you have some choices in how you approach a story wall. You can try different approaches and then change it each iteration, based on the lessons you gain from your retro. You can also use a story wall where you have no iterations.
I will provide some more options soon and will look at a couple more different approaches soon.
In the meantime though, try something out and improve it as you go. Good luck and let me know if you have any improvements, questions or suggestions.
James King 