Scrum © royskeane@flickr
We are agile. We do Scrum. We do daily Stand-ups.
A couple of weeks ago we changed our daily stand-up meeting. Our Scrum master came up with the idea to not go around the whole team and everybody talks about what he has done, what he will do and what the impediments are but to make it story based.
Usually after a break down everybody was working on one story, saw the task cards and made sure he did the things he was supposed to do. But this is not enough. You need to have an overview of the whole story (and the sprint). Only with that knowledge you can make sure you will meet the commitment.
So what we started to do is a stand-up meeting based on stories. Every story has a story owner. This is either the person who first started on this story or somebody who is expert in the field worked on. Every morning he is giving a review of how ‘his’ story is progressing, where the problems are and how he could need help. Depending on the priority he gets everything he needs. After presenting the status to the whole team every team member involved gives a smiley on how he feels about the story and the sprint. This way everybody knows what the situation is and how the sprint is progressing.
We found this very effective and it gives every team member a much better feeling about our commitment.
You should try it too.
You are doing scrum, your story is big, you really don’t know much about it and the feature does not get implemented in time.
Sounds familiar ?
I had this a couple of times.
What turned out to be a real problem is that, tech nerds as we are, we spent most of the time coding up a nice solution (and we were almost always convinced that this was the minimum we should have done). What we underestimated was the time we would need to integrate it with the rest of the system. When we broke new ground integrating new technologies it turned out is is very easy to miss that point.
In theory ‘just’ code against a defined interface and you are all set up. In practice you will find the interface not working as intended or web services returning everything wrapped in CDATA. This is the point where you start to panic. This integration was supposed to be easy. Everything else is already working and only a couple of hours where allocated to integrate the new functionality (and sprint review is tomorrow). So it is crunch time, again.
What did we learn ?
If possible (and this is not always the case) start implementing one small feature from top to bottom all the way through your application, e.g. selling green cars through you web site. If this works you can go on and sell blue and red cars. It also helps to organize teams along user stories. This way everybody is responsible for the story.
If you have teams organized along responsibilities like database or GUI, the communication between the team members will suffer (since they usually sit in different rooms). Everybody tries to code up against the defined interface and the integration usually happens pretty late in the sprint. Each team claims that his stuff works against the agreed contract (but still some things do not function as they should). Just hours before the integration should be finished, it turns out the specification was not correct and other things are needed. Back to the drawing board. Overtime. Feature not implemented.
After you got the integration running make sure an automated test is covering it. These need to be expanded over time and you make sure from the beginning that it will always work. It would be very nice to have the integration test running before writing any actual code (read: test driven development) but this never went to well for me since the two sides are very fuzzy in the beginning.
My hope is that next time we come to a situation like this I remember a couple of things I wrote down here 
.
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
