If you’re using Scrum in your organisation to develop software, then you are very well aware of the challenges of getting your Stories spot on. Writing a good User Story is not easy; it depends on both business and development factors.
The ideal Scrum Sprint planning is fast, the estimation session does not drag on, however usually the reality is nothing like that and both the Product owner and the development team are equally to blame.
Many questions raised for each User Story; unclear acceptance criteria; missing artefacts, unresolved cross-team dependencies, unresolved 3rd party dependencies… The problems are far more apparent when the Scrum team (product owner, scrum master, development team) is distributed….
This is sounds familiar? Then read on!
If you’re seeing all that problems appearing in your software development activities then you’ve something to worry about. This issue is common industry-wide and there isn’t a Silver Bullet to attempt to gun it down. Nevertheless I am going to suggest a practice here that may help in many cases crack this issue, make your Sprint plannings very short and save time, energy and supposedly help to boost motivation.
The practice is using a tool called Story Status and here’s what you need to do:
- If you are using Jira/GreenHopper, Agilo, or any other configurable Scrum lifecycle management tool, then what you need to do is to configure a new multi-select field to appear in the list of parameters for the Story… Name that field Story Status.
- Think of all the things that the readiness of a Story to be included in a Sprint depends on. You may want to consider things like
- Needs UX design
- Misses Artefacts
- Misses 3rd party documentation
- Needs input on Tracking/Analytics
- Needs Technical feedback
- Needs Architectural Signoff
- , and so on
- Add all of that to the list of possible selectable values for that parameter. Additionally also add “Read for Sprint” to the list.
All set? Here’s what needs to happen.
The persons in charge of creating User Stories create the Stories for upcoming Sprints in the (unscheduled) backlog. These stories are as a general rule not fully elaborated and need further clarification. In every Sprint planning, the development team plans time to spend studying the backlog and upcoming stories. The Scrum master organizes weekly half an hour sessions for the team to have a quick look (not detailed) and see what the potential stories for upcoming Sprints look like. Team members raise questions, if the questions are not answered and/or solved within the developers, qa and ui engineers, then the questions are raised as comments to the ticket. More importantly the appropriate items from the Story Statuses list are selected to highlight to Product Owner what needs to be further provided to make the story ready for estimation.
This technique helps highlight to Product Owner what state each of their Stories are, and makes it easier to get stories ready for sprint. Once all questions are clarified, no further dependencies exist and all artefacts are provided, then the development team (and only the development team) can change the story status to “Ready for Sprint”, while also estimating it in a Planning Poker, to save precious time during planning.
The Story Status technique is especially useful for organisations that have the Scrum Team working distributed, especially in cases when Product Owners and Development team are not co-located.
Have you been doing something similar? Or tried this after you saw here, share your thoughts!