News

Most Agile teams use story walls – either physical walls or online tools to store their stories.

But a lot of those teams see the wall as a burden rather than a tool that makes life easier for them.  This is a shame because the only reason you want to have a wall is because it makes it quicker and easier for the team to get their work done.

From the perspective of the TEAM, the story wall makes their work visible so that they can more easily collaborate and get things done.

Since different teams work differently, they are likely to want different types of story walls. This is the first in a series of articles that run through different types of walls that might be useful to different teams. There is no best practice – just things that suit different teams.

An extremely simple wall

Let’s start with a really simple wall.  This team creates a new story wall each time they start a new mission (Get a new mini-project, start a new sprint or just agree to organise the team Christmas party).

The team create cards for each task they need to complete (eg requests to fulfil, steps needed to get ready for the big show, the audits they want to perform etc).

They put all these cards up on the wall in a section called “open.”

Then as they complete their work, things start to move to the “closed” space. Eventually, everything is closed and they are finished.

The team can have a stand-up every day where they get together and tell each other what they are working on … “yesterday I completed this one, today I am on this one.”

If an impediment comes up then they can say “my impediment today is blah” and add it to the open list. They can do this in a different colour or just use the same index cards.  Once an impediment is removed it is closed just like a task.

If a team member has to add work (say a defect or unexpected) then they can just add it to the open section and move it when they are done.  Unplanned work could be in a different colour but is probably just on the same cards.

Once they are done they can refer to all the cards in the retrospective and look at which ones went well and which went badly.

Variant – Daily focus wall and meeting

Instead of having a planning session to add cards to the wall, the team can simply update the wall each day in a rolling daily meeting.

1. The team meet at the task wall each morning at 9 am.
2. Everyone says what they finished the previous day, moving those things to the closed section. Cards are left there until the end of the week in case people want to refer back to them and to create a feeling of progress over the week.
3. People also explain what they will achieve today. They are limited to 3 priority tasks.
4. If someone has a major impediment or concern (issue/concern/risk/thing they are not looking forward to) then they add this to the wall.  If a new impediment takes its place they close the old one and add the new one.
5. If concerns or tasks just go away without being done then they get thrown out.  Some teams add them as “rejected” but then you need a third section.

A task wall with goals

Most Agile teams have a wall with columns in.  Sometimes it has stories moving on the wall and sometimes it has tasks. Let's look at a team that has goals for the sprint and then tasks to complete in order to achieve those goals.

This team works in fortnightly sprints.  But they do not just punch out features for an IT system, they set goals that they need to achieve.

So at the beginning of each sprint, they meet and agree what needs to be achieved for the sprint to be successful.  These are listed as the goals and they might be things like “users can access audit trails,” or “Run the dress rehearsal for our new play,”

Once they set their goals, they discuss the tasks that need to be completed and add them to a column called “tasks.”  Then they add an extra row on their story wall to show housekeeping work that just needs to happen but does not hit any one particular goal (run stock-take, build test environment etc).

Once they have agreed the tasks, most teams confirm that completing the tasks will mean they achieve the goals.  Ie “If we do these things, then this will be achieved.”

The meeting ends and they start work. Each day they have a stand-up where the team members say “yesterday I did this task and today I am doing this one”.  If they have impediments then they mention them too.

The wall then evolves each day. Tasks move into the “working on this today” column and then the “done” column.  Once all the tasks for a goal are in the done column then the team has stopped working on that goal.

Once all goals are achieved the sprint is successful.  That means the showcase (where the team demo the work) can include a demo of each goal attained. Similarly, the retro can include a discussion of what worked and didn’t work in pursuing each goal.

If the sprint ends with some goals not yet achieved, then the team demo the things that have been achieved and decide what to do about the others next sprint.

Usually, that means finishing old goals off in the next sprint but sometimes the team might just drop a goal because it no longer seems as important or it all got too hard.

Of course, during a sprint, a defect might appear or an unexpected task might come up.  So the team just add this to either “in progress” if they are doing it today, or “tasks” if it has to be completed another day.  Thus writing code, putting on a dress rehearsal, fixing defects are all just tasks to be done to achieve a goal.

I sometimes add unplanned work as housekeeping and then do a rough estimate at the end of the sprint of

• The percentage of time focused on goals (say 30%)
• the rough percentage reacting to unplanned requests or doing stuff not related to our goals (say 70%).

Then I use this rough percentage of time for my retrospective and often for planning my capacity in future sprints.  You can even produce a graph of where your energy was spent each sprint to see how much time you are able to commit to the (allegedly important) team goals:

Variant – estimating tasks and a burndown chart

Just adding tasks without estimates can work pretty well. But some teams want to track things in greater detail.  So they plan and track time as well as tasks.

In the sprint planning session, the team decide on goals and then agree the tasks needed to achieve them. But now they also provide a rough estimate of the time each task will take.  This is not a rock-solid commitment based on a detailed analysis, but rather a best guess based on current assumptions.

By estimating the time taking for all the tasks, the team better understand when to stop planning.

For example in a team of 10 people working on a sprint for 10 days, there are 10 x 10 x 8 hours available (800 hours). But of course, the team will not spend their time that efficiently – so they might agree to plan 33% or 50% of their time (say 400 hours).  This way they can be more confident they are planning for something challenging but achievable.  It also means that each sprint the team can become better at estimating how much they can commit to.

Once the team start work the daily stand-up changes slightly too.  People still say “yesterday I completed this” but now they say “Today I am working on that – there are about 2 hours left on this task.”  That way a team member can clarify when they will finish and also explain when a task has ballooned out beyond what was expected.

Team members can also say – “we found a defect which I have added here, that will add about an hour to fix,” or “we realised we need to do that, which is about another 4 hours we didn’t plan for.”  Happily, they can also say “we realised we don’t need that task so we can close it, saving 2 hours.”

Where teams track their time like this, they often use a burndown chart to show progress and the likelihood of finishing everything:

The team (or their facilitator) graph how much work needs to be done (say 400 hours of tasks) and how many days they have left in the sprint (say 10 to start with).

In theory, work should be completed at a consistent pace and the team should finish the last hour or work in the last hour of the sprint. But of course, this does not happen.

Nobody cares how much work has been done, but by checking each day (hours of tasks left against days left) the team often see a trend and can better guess if they will complete all their goals this sprint.

This knowledge might lead them to be more confident each day. It could also show them they are doomed, in which case they can stop and re-plan from scratch. Or, most often, they can use this information to re-prioritise and refocus on the most important work to get the best outcome possible in the sprint.

Most common variant – stories with tasks

Most Agile teams work with stories. The approach is exactly the same, except they replace “goals” with “stories”.  Then they break each story into tasks and work through them.  Again, once all the tasks for a story are completed, the story is done and it is ready to use.

This works really well for many teams and that is about as complicated as things need to get.

But other teams use different types of walls, for example a story wall where stories progress through “being elaborated,” then “in development” and then “in testing” and finally “done.”  The stories never get broken down into tasks in this approach but rather evolve from “start” to “done.”

Other teams use different ideas to communicate different aspects of their work.  So next week I will go through some different approaches.

Post by James King