May 25 2017
Almost every team has faced a situation where it’s perfectly obvious that a story doesn’t have much of a description, but the decision to go ahead is taken anyway. However, it’s not long before everyone realises that ‘going ahead’ isn’t possible without more questions and clarification. The result? An unnecessary delay.
One solution is that the client signs up to a ‘Definition of Ready’. This means the team is committing to provide certain information before a story is classified as completely ready to be worked on.
The DoR document includes elements such as:
DESCRIPTION *Short Description / Business requirement* STORY As an: *Type of user* I can: *Some goal* So that: *Some reason* ACCEPTANCE CRITERIA Given: *Some context* When: *Some action is carried out* Then: *A particular set of observable consequences should obtain* ..... *As many as required, happy and sad paths* ASSUMPTIONS *Any Assumptions* TESTS *Types of Tests required* NOTES *Any Notes*
Independent - The user story should be self-contained, in a way that there is no inherent dependency on another user story. Negotiable - User stories, up until they are part of an iteration, can always be changed and rewritten. Valuable - A user story must deliver value to the end user. Estimable - You must always be able to estimate the size of a user story. Small - User stories should not be so big as to become impossible to plan/task/prioritise with a certain level of certainty. Testable - The user story or its related description must provide the necessary information to make test development possible.
Nevertheless, even if this document is agreed with everyone on the team, there may be stories that get pushed into a sprint before ready and the team is back to square one.
We are all familiar with work boards in Jira or similar, so I thought that it would be a good idea to create a workflow that would facilitate the creation of a story right through to completion. I took the main steps from the DoR and a separate Kanban board, to enable a story to meet the DoR. Only at this point will it be ready for the sprint.
Initial creation of a story, may only have a title or just some notes in the description. A story can be created by anyone in the team.
Ready for Refinement
The product owner and the project lead go through the story and flesh it out by adding a description.
Ready for UX/Design Review
Now that a story has been defined, the UX/designer can review the story and create any wireframes/designs that are required for the story.
Ready for Sizing
The team (PO, PL, SA, Dev, test, design and UX) discuss if there is enough acceptance criteria, if and how the tester can test it. Then the whole team sizes in story points.
Ready for Backlog
The story now meets the DoR and is ready to be pulled into the backlog.
The story is waiting to be picked up.
Development In Progress
This issue is being actively worked on at the moment by the assignee. This should be in its own branch, off the development branch and named the same as the Jira ref, eg RFI-2301.
The story is complete, the DoR has been met and a pull request has been created. Developers should look at this column when they finish each story and review all stories before starting the next one.
Ready for Testing
The story has been reviewed by two developers, merged into development and is ready for the tester to pick up.
Testing In Progress
The tester tests the AC for the story, looking at both the happy and sad paths.
The story is complete, both tested and signed off.
There is now a workflow in place that will compel people to think about a story multiple times as it flows through the states. A story could still be pushed through to a sprint without meeting the DoR, but the whole team would have failed if this happens.
For the best outcome, it is essential that the agency team has completely thought through the delivery plan and its technical implications, and that the client team understands the process, and the effort required throughout the planning process.
About the author