Organizing Principles |
Making business purposeful, passionate, peaceful & profitable.
Facing a challenge? Ask a question > Also on Twitter @EvanLeonard |
| I just answered this question via Aardvark: | |
| Aardvark User: | In scrum, when does an impediment (with tasks) become a story? |
| Evan: | An impediment usually would never become a story, unless there is engineering work required by the team. The impediment list is owned by the ScrumMaster and is work on by the ScrumMaster and anyone else the ScrumMaster solicits help from. Any time that impediments take to work on should not be counted in the team's velocity. That time is simply part of the "drag" on the system. When the impediment is removed its drag can be measures by the increase in the teams velocity. |
| Aardvark User: | Good info, thanks. This impediment required several hours of engineering work. Would you recommend this become a story if it's already been worked on and resolved? |
| Evan: | There's two schools of thought on this. My take is that it depends on what you are trying to measure. Are you trying to measure the capability of your organization to deliver end-user functionality? Or are you trying to justify the existence of your team to higher level management? In the first situation you might add an item to the backlog but assign it zero value. In the later situation you might add it to the backlog with a positive value. |
| Aardvark User: | We are probably somewhere in the middle. We want to establish an accurate average velocity and prove to management we are doing the work. I will probably go with creating the story and having the team determine the size. Thanks for the help! |
| Evan: | You're welcome! |
