Backlog Story Checklist¶
I have found that the quality of the stories on the backlog are important in Scrum and Kanban. When the process isn’t working well the root cause is often that the stories are not well defined, too large or describing something other than a piece of functionality that is valuable to a user.
Here are a few items that I’ve found to be useful in the past:
- Is it user facing, and not written in terms of implementation detail? Consider expressing it in the pattern ‘AS A _____ I WANT TO ___ SO THAT ___.’ The story should answer all three of those blanks: Who? What? Why?
- Does it identify specific work to be done?
- Does it have an estimate?
- If it relates to a bug, include the bug reference number. If it describes a bug but it isn’t in Jira (other bug tracking tools are available) then create an issue for it. Ensure that the bug contains:
- Has it been reproduced in house?
- The name of the test case (if any) that fails. Is the test case automated?
- Are there success criteria?
- Could it harmlessly be split into two stories? If so, split it: smaller stories are better.
- Does it produce log information for support? If so, run it past them. More generally: run through the story with any people outside the team who may care about it.
- Run the story past the team who will be implementing it.
- How will we know we are succeeding at the underlying business goal? For example: ‘Because 50% of the people evaluating will successfully use the remote installer’
- How will customers find this feature?