We’ve been working with Scrum for a while now, generally successfully. However of late, as the pressure has started to mount up we’ve encountered several situations where items came through planning meetings but when it actually came time to code, it became apparent they were woefully under-specified.
This is an annoying and awkward waste of time. So I’m wondering, is there anything we can do to make sure that a work item is properly understood and planned before it’s included in a sprint?
We don’t use TDD, but my experiences with it suggest that it’s a good way of ensuring a programmer understands a task before beginning work. So I did consider trying to work out some automated testing as a possible approach to this. But not all work items are amenable to automated tests, and it’s likely to be difficult/boring for non-programmers in the meeting.
As an aside, out of curiosity, is when one has decided on acceptance criteria, should they go on a work item, or a user story, or both?
INVEST is a good mnemonic to use for measuring the quality of your stories and getting better at writing them. The mnemonic states that a good story should be:
- 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/prioritize with a certain level of certainty.
- Testable: The user story or its related description must provide the necessary information to make test development possible
You should also invest time in backlog grooming sessions. These should be well in advance before the sprint planning. Here you improve the stories, find out if you need more information. In sprint planning, you should refuse to take on stories that are too vague. For this evaluation you can use the above mentioned INVEST.
Often I found myself breaking a story in two stories: the first one contains the clear must-have parts and second the more vague or “nice-to-have” features. The first one is accepted to the next sprint and the second is groomed during that sprint with new information gathered from stakeholders and from implementing the first part.
2
One of the scrum ceremonies is grooming, you can make use of that meeting during each sprint to groom about future PBIs that your team is going to pick. In the meeting the whole team (Software Engineer, Quality Engineer, functional designer and SM) gather around together with Product owner and mostly it is FD and PO job to explain and describe the user stories and team can elaborate about how it is technically possible to implement and be tested (And make sure you document those outcome if it is possible for future reference). And in case you need to break the PBI or there are some notes you can decide in the grooming.
Also in planning you can also remind each other just briefly about the PBIs implementation blue print and testing scope.
I am not sure about the technology that you use but for example in tfs you can define PBIs and tasks and put all of those detail and outcomes of meeting into PBI so when programmer picks the it, he or she knows about background of PBI and all the requirement.
Individuals and interactions over processes and tools
Go back to the user and ask for more clarification, details, etc. I know this isn’t always possible and can be annoying to both sides, but it’s better than coding in the blind. It may help both sides understand what everybody really needs to know before coding.
There are plenty of techniques to make sure you have a good story, but it still requires a little practice on both sides.
It will seem inefficient early on, but it won’t waste as much time in the long-run. If you feel like you have to be perfect coming out of every single planning session, they’ll never end, so take on a little risk knowing you can always go back and ask. Hopefully, there is time for these contingencies and soon they’ll be the exception rather than the rule.