So just in the last sprint we (re) discovered that we need an owner of each story. A person who makes sure things are going smoothly and takes care that everything is done in a way so we can fulfill all acceptance tests. At sprint start the person which feels the strongest about the first story will be owner and he will drive the story.
Very often we do operate in a king and servant model. The king (story owner) calls as many servants he needs to get ‘his’ story (with the highest priority) done. If this story does not scale to the full team the others are starting on the next story. Again, a story owner (king) is chosen (or whoever wants to drive the story). Of course story priority is always determining the order of allocating resources to finish the job.
To formalize the story owner a little bit we do write down the name of the person in the upper right corner of the story card. I updated the scrum board cheat sheet.
Get version 1.1 of the Scrum Board Cheat Sheet.
In the last couple of month we continuously improved our scrum task board. After a sprint planning we usually do a story breakdown into tasks. All tasks for one story get ordered and a time for each will be estimated. We do try do make sure every task is smaller than 8 hours so it can be completed in one day.Our ScrumBoard is a magnetic whiteboard with hand drawn lines.
We do use color coded cards for the tasks we do. We do shuffle the colors each sprint but we have different colors for:
- The Story itself
- A Task
- Unplanned Task (like a thing we forgot at breakdown)
- High Priority Bugs which need to be fixed right away
- Non Sprint Tasks
Different colors make it easy to see if we were good at estimating the work which needs to be done. It shows us very easily that we might be in trouble with our commitment because we got of external tasks. The burndown chart shows this as well, but the colors show us why (as well as the bars, more on that later).
The top row is reserved for unplanned tasks, bugs and time boxed events such as workshops with the solution owner or support for the product owner. Four rows are for stories we are working on.
As soon as somebody starts a task he writes his name on the task card and puts it in the ‘work’ column. He usually takes as many cards until the added hours of the tasks equal the time he is available to the sprint today.
Each card has a specific order in which it needs to be executed to complete the story. Some tasks could be executed in parallel and some have to wait. If we find one card blocking and somebody is working on it, the rest of the team sometimes starts with a new story or helps finishing the blocker. Right next to it we draw a small bar for each day we are working on this task. When we see that a task which should take e.g. 4 hours is now in the ‘work’ column for 2 or more days then this needs to be addressed in a way that we brake this card further down or assign more people to it so this can be finished. Bar code cards are not cool.
If a task is done, we put them at the end of the row in the ‘work’ column in 90 degree angle. This card will be moved the next morning during the 15 minute daily scrum to the ‘done’ column. If something comes up during the daily scrum which needs to be discussed by the team we write this down in the Standup Backlog at the board.
To get a better impression have a look at the ScrumBoard Cheat Sheet of my team.
Update:
This is our current sprint overview:
Our current scrum board
