Well defined stories: The key to eliminating work flow delays?

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.

DOR

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:

• The story has been created in Jira.
• The story has the following template:

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*

• The story should adhere to the The INVEST mnemonic:

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.

• The story is well defined and understood by the team.
• Dependencies are identified and understood by the team.
• Acceptance criteria must exist and be understood by the team.
• UX sketches exist, where appropriate, and are understood by the team.
• UI sketches exist, where appropriate, and are understood by the team.
• The story has been estimated by the team.
• The team understands how to demo the feature.
• How to test story has been discussed and understood by the team.

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.

Introducing the dual board

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.

Preparation Board States

Draft

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.

Sprint Board States

ToDo

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.

PR Review

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.

Signed Off

The story is complete, both tested and signed off.

Conclusion

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.