Happy New Year @gile$cout readers!
Be it teams new to Scrum or ones that have been practicing scrum for a while, one of the common problems they face is: User stories carrying over multiple time boxes (sprints/iterations). The team simply can NOT finish the story and it drags on..and on..sprint after sprint.
As a member of ever growing agile community, I am subscribed to many discussion groups. Recently, one such discussion Can’t get to done, roll-over every sprint on Scrum Alliance Google Group caught my attention.
The origin of the problem can be at many places like: Ambiguous requirement(s)/stories, Stories not sliced enough, Business owner/PO availability, Technical road block, Team member availability etc. One of the common cause is “over commitment”. I’d like to share my recent experience about this specific problem and how I was able to address it.
Setting: Most of the team members were new to scrum/agile. 3 Sprints into the product development, our team was continuously moving more than a couple of user stories from sprint to sprint. Apart from the obvious problem of inexperience with user story creation and splitting, there was a zest in team which was leading to over commitment.
Having failed to try and discuss that problem in retrospectives, I had to wait for around 3 sprints to validate my assumption. (Yes, we progressed into creating better stories and got a little better at slicing them). After 3 sprints, I decided to try something different – I created a new backlog item “Spillover” stories for the next sprint. Since Thanksgiving was approaching people started talking about Turkey dinners and thus the “leftover” turkey sandwiches and all sorts of leftover recipe discussions were making rounds in office and internet. That inspired me to use the term “Leftover” stories.
At every daily standup, we would discuss about the “Leftovers”. And as it happens in every household, there came a day when the team got bored with leftovers. One of our developers broke the silence saying, “..I don’t like the term leftover/spillover you are using..”. The developer was concerned that the task board was not doing justice to the status of work completed in that story. That was the opportunity, I was waiting for.
We agreed to finish the standup and then discuss the issue. With everyone from the team present there, we looked at the stories, work history, capacity of every team member and turned the discussion into a retrospective. Everyone agreed that we had gotten better at describing the user stories, creating supporting documents/design/User interface. The team then realized given the time box, we were biting more than we can chew. For the first 3 iterations, we all were ignoring the fact as the team was forming, storming. It WAS a team commitment (or “lack of” to say NO to the product owner) issue.
This experience touched many aspects of the team’s operation, but mainly addressed the commitment issues. We do have some scrum certified team members but until we practice, fail, inspect-adapt and repeat the cycle, we are not being true to agile values and principles. It was a wonderful experience for me and the team and we all have made adjustments since then.
Many other scrum/agile experts offered excellent advice/response to that thread on Scrum Alliance Google group. I shared this story very briefly. I was delighted to see @RonJeffries responding to my response on the group as “Nice!” Made my day! [blackbirdpie url=”https://twitter.com/RonJeffries/status/268815166001532929″]
Thanks to @WoodyZuill for encouraging me to create this post out of a twitter conversation! [blackbirdpie url=”https://twitter.com/WoodyZuill/status/282132950387138560″]
If it helps, here are some of my User Story related valuable reads. I know it’s time to update that list! I am eager to hear your comments and stories.