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.

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″]

Nice to read about your experience. I run into way too many teams who, eager to please their stakeholders, consistently take on too much work.

I think the Scrum practice of “commitment” (which, by the way, is now removed from the official Scrum guidelines) is partly to blame. The idea of “committing” to some number of points or stories or hours of work for the next N weeks – how does that make us work harder? If your team needs a “stretch” goal, then you don’t have the right people. Everyone on a dev team should be the kind of person who loves to do their best work, and management should make sure they are able to do so, not club them over the head with “you didn’t commit to enough” or “you blew the sprint because you didn’t complete all the committed stories”.

Stop committing, or at least, under-commit. Always better to bring in more work. Limit WIP, focus on finishing one story at a time.

Better yet, do as Sameer’s team did – have retrospectives, identify your biggest problem, and try an experiment to make it a little bit less of a problem.

Under committing or having less work in sprint makes many product owners insecure. It’s interesting to see on the same team people with two different ends of spectrum trying to make their point.
It’s healthy to recognize the differences and bring them to table but it then depends on the dominating personality what happens next.

It’s sometime mentally taxing for team members. I wish we could introduce more people to probably core protocols.

I am learning a lot. One thing is for sure, scrum/agile community really needs to do a better job of educating people that by embracing these practices, teams will bring out all sorts of their problems out. Be ready to deal with them – that’s all.

IME, customers are so used to getting *nothing*, that getting a little is pretty cool. We educated our biz people about technical debt, and helped them understand that focusing on speed will lead to so much technical debt that we’d slow to a stop, but focusing on quality will eventually lead to speed.

Sadly, though, too many companies are all about right now or this quarter and the long term doesn’t matter. When companies lay off their highest-paid manager so they can report a double digit profit, they aren’t going to care about technical debt. But then you get into the situation of “if you can’t change your organization, change your organization” (who said that? Martin Fowler?)

Trackbacks/Pingbacks

[…] 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). […]