When the Story is Not Done

Things go wrong during sprints.

One of the most important facets of agile is the quick cycle times make it possible for people to react to change rapidly.  The end of each sprint is an opportunity to gauge success and look for areas of improvement.  The speed forces us to do work in smaller chunks and gather feedback and direction from customers.  An agile team can bite off more than it can chew in a sprint.  Today on my blog, I want to discuss some recommendations on how to handle stories which take longer than a sprint.

In a perfect agile practice, each team completes all of the work they commit to in a sprint.  The need to “roll over,” critical work to the next sprint does not happen.  In the fallen world where most of us live and work, stories do not get finished at the end of the sprint.  It creates a challenge because the unfinished story might delay a release or throw a delivery timeline off schedule.

The Scrum Guide does not say much about what to do when a story is incomplete at the end of a sprint.  Since there was no consensus, a beginning scrum master just rolled over the story and asked the team to finish the work in the next sprint.  The approach was no different than letting a milestone slip in a waterfall project.  The collective wisdom of the web stepped forward, and experts suggested an incomplete story should return to the backlog and reprioritized.  If the story still had value it can be placed in the subsequent sprint; otherwise, it can wait.

Concentrating on what is important rather than what is unfinished each sprint is what makes agile so powerful.  Unfortunately, unfinished work can become technical debt overnight and create conflicts inside the agile team.  Many stories are incomplete because the team has not met the standard of care for the story.  Unfinished unit tests and incomplete acceptance criteria are prime culprits for this situation.  The group wants to split the story and lower the number of story points so that it does not look like the velocity of the team is impacted.  The truth is velocity is affected.  The team failed to deliver story points in the previous sprint, so the velocity has gone down.  A team should both see and feel the effects of not meeting the standard of care.  People outside the team should also see an honest portrayal of the challenges the team is facing.  There should be no secrets on an agile team or in an agile enterprise.

When a team fails to deliver this is also an opportunity to bring up in the retrospective what caused this kind of setback.  Product owners should understand there is more to a story than writing code and developers should be more assertive about how they communicate.  The team should own up to the failure and try to do a better job next time.

Failure is hard, but it educates better than any success ever could.  It also makes future victory sweeter.

Until next time.