BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News How to Handle Unfinished Stories?

How to Handle Unfinished Stories?

This item in japanese

Bookmarks

It is not uncommon for a scrum team to get to the end of the sprint and find that they have a story that has been worked on, but is not yet done. Perhaps the story appears to be about 80% done. What should become of such stories and how should the progress made on them be tracked? These are questions that every agile team will face. In a recent blog post, David Starr shares his approach.

One way to track progress is to give 80% of the point value of the story to the team for the current sprint. At first blush, this approach seems to accurately reflect the state of things, and may help keep the team's recorded velocity from varying up and down, sprint to sprint. It also has a certain amount 'feel good' value for the team. However, this approach has significant risk. The story is not verifiably done and the amount of time and effort that will be needed to get to 'done' isn't really known.

A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done. To the extent that some of the smaller stories are truly 'done', this can reduce the risk associated with the 'partial credit' approach. It also allows the product owner to make some decisions about the relative importance of the unfinished stories.

David finds all of the 'partial credit' approaches unsatisfactory and recommends that team be given no credit until the original story is fully completed. He recommends that the story be re-estimated and put back in the backlog. In David's words: "This model keeps things simple and keeps teams from gaming the numbers."

How does your team handle partially done stories? Post a comment and share what is working, and what isn't.

Rate this Article

Adoption
Style

BT