Product wall details: scrum section (3/4)
This is the third post in my series on our product backlog wall. The first two posts were about the strategic section and the backlog section of the wall. This section describes the way the team visualizes our sprints. Our scrum board has 6 sections.
The story section (1)
Our scrum board is a pretty default scrum board with user stories broken up into individual tasks for the team to pick up. As soon as every task is done the story gets placed in the busy column. This means the product owner can test the story on our test environment. Once the story has been approved by the product owner he moves it into the done?? column. The question marks are not there because we’re not sure the story’s done. This column is used so that the next day one of the developers can demonstrate the story to the rest of the team. We call this an in-sprint-done celebration. We do this to motivate the developers but also as an opportunity for some early feedback. After the story has been demonstrated it’s moved to the done!column and the points are burned.
The sprint progress graph (2)
The sprint progress graph shows the amount of story points picked up by the team and is a basic burn-down chart. We don’t burn hours because it can give a false presentation of progress. If you’re working on all stories at the same time you may very well seem to be on progress the entire sprint and at the end deliver no value because all your stories fail (believe me we’ve been there). By focussing on story points it helps us to pick up the top priority story first and then work our way down accordingly.
The team’s definition of done (3)
The definition of done is always prominent on the scrum board. It’s the rules the team has given themselves when delivering stories like functionality should contain unit tests, we either peer review or pair program and other stuff.
Our impediment corner (4)
We actually use this spot on the scrum board for everything that happens during the day that needs to come back in the next standup meeting. We encourage the team members to use this spot on the board and urge everybody to participate in identifying and solving impediments.
The tech debt corner (5)
As a product owner I do not always know exactly how the code looks and if we have created technical debt in the software. I know some teams don’t register technical debt and just fix things without necessarily informing the product owner. I personally like to be involved and now what problems the team encounters. Whenever a team member runs into a piece of code that he thinks should be re-factored or sometimes even rebuild, but it’s not really part of the story he’s working on, he will put it in the tech debt corner. This gives us the opportunity to bring it up during the stand up and if the team agrees I make a story and put it in the backlog so the team can pick it up in a future sprint.
Parked section (6)
We like to push ourselves a little bit and pick up a challenging amount of story points each sprint. Occasionally we don’t get all our stories done in a sprint. If we see that happening, we take a story of lower priority and put it in the parked section. We then pick up that story in the next sprint.
Like this post?
I expect to be writing a fourth post on our maintenance section soon, so keep posted.
Please feel free to give your feedback in a comment.
Related articles:
