I would like to share a story with you. Our development team started using Scrum half a year ago. At that time, I shared a concept with the team: King-Servant pattern by Henrik Kniberg [1]. The benefits of using this pattern for us would be: Improve focus and teamwork to deliver the most important functionality at the end of the sprint. Sounds great, huh? However, my pitch for applying the pattern was not compelling enough for the team to go for it. I was disappointed at that time, because I believed it would work for us.
A few weeks ago, the team created the following improvement goal for the upcoming sprint (two weeks): “As a team member, I want more insight in the sprint so we can make our deadlines”. My natural tendency is to jump to practical solutions, in this case give a speech about the correct use of a burndown chart. But I remained silent. The ideas were: “Give a user story a deadline date within the sprint”. “Create a story timeline for the next sprint”. “Make one developer responsible for finishing the story before the deadline”. So, we tried it out the next sprint. You can see the picture of the story timeline below. Note: there is one timeline per product (X and F).
How did it go? In my perception, developers had a greater focus on delivering the stories they were personally accountable for. They naturally approached their colleagues for help. Everybody was helping along to meet the self-imposed in-sprint deadlines. In our last retrospective, the team decided to pursue this way of working because it was working for them.
Do I believe story timelines are a better solution for gaining insights than burndown charts? I do not, but it is working for our team! Why? Because the team acknowledged a problem, invented a solution and committed to the implementation. All these steps are done without intervention by management. Therefore my statement is: Stop micro-managing, start trusting your people. They will impress you with the results.
What do you think about it? Let me know!
Regards,
Rob
Twitter: @robvanlanen
Blog: http://www.fanlan.nl
[1] Henrik Kniberg: “Scrum & XP: Beyond the Trenches” (slide 45-48).
Similar posts you might find interesting:
I could not agree more.
The developers taking, not placing, responsibility for a story makes them more committed in getting the job done. They will encourage and try to help each other out more quickly, if meeting a certain deadline appears to be difficult during a sprint.
Though, one pitfall that needs to be addressed is the meeting-the-deadline-shortcut-decisions that results in crappy code. The developer will say something like ‘But the story works! Doesn’t it?’
Nice article! It is all about self-organization! You should not care how they do it, apart from guarding the Scrum process off course.
About the pitfall mentioned above: this is where the definition of done comes in. The dev team and product owner agree upon a definition of done. I would encourage for the team to put quality characteristics of the delivered software in there. The product owner is responsible for inspecting the software according to the definition of done.
Regards, Paul