No Points for Second Place
~ by Randy Wagner
The Story’s Not Over — Until It’s Over
Demonstration day for a story is a delight when it flows smoothly. The product owner accepts the work because the needs of the organization have been delivered and the QA’s work is validated. This is the moment when a story truly closes. It’s also the only moment points should be awarded. Unfortunately, for many projects, the temptation to show progress can be too great and justifications are made for why they should be pre-emptively taken. Like so many other shortcuts, this is one that will haunt project teams for sprints to come.
What’s the Harm in Dev Taking All the Points?
The recommended agile approach is to do requirements, development, testing, and acceptance within a single sprint. That paradigm often falls prey to the realities of time and expense.
- No one wants the Devs and QAs to sit idle while the BAs define the story card so BA work sneaks ahead to the N-1 sprint.
- Development works in the N sprint to complete the work, but all too often delivers too late in the sprint to allow for adequate testing.
- QA slips to the N+1 sprint. That is not inherently bad because it keeps everyone productive.
Where it gets troublesome is where points are taken.
Sprint planning defined what will be completed and no one wants to show that 70 points were projected in a sprint that only delivered 52. Development completed the work and demonstrated that it functioned well enough. Isn’t that good enough for taking points? QA is only going to validate it. Nothing will really change, right? What’s the harm?
Why Can’t QA Points be Pushed to the Next Sprint?
The bill always comes due. That is true in so many areas of life when shortcuts are taken. It’s doubly true in agile development. So, we reach the end of the sprint and we’re not ready to demo the story. If you take the Dev and BA points, QA is assumed to be a foregone conclusion. Promises are made that all the product owner’s concerns will be validated in testing. The story gets split and some points are taken, the QA points push to the next sprint. That is where the trouble really begins.
#1 – The Allocated Points for QA are Almost Always Too Low
First, Dev demos are consistently positive testing events. A field was requested and now the field shows on the screen. Done. Unfortunately, it is often the negative testing that reveals the defects. Are the field boundaries set correctly? Does it refresh appropriately? What if you change related fields or leave them blank? Sprint planning is supposed to allocate hours for defect identification and retesting but that depends on the clarity of the requirements, the skill of the developer, and the creativity of the tester. The allocated points are almost always too low.
#2 – QA-Only Ticket is Split Time and Again to Create a Breeding Ground of Defects
Now we are in the following sprint and QA is still cleaning up points from the last sprint. Maybe the defect isn’t as critical, so it gets lowered on the priority list. The QA-only ticket gets split to gain some points and yet another ticket is pushed into a later sprint to linger. What matters most here is that it’s often these lingering tickets that become fertile ground for other defects. Stories that were not closed out correctly up front create tripping hazards for stories in later sprints. We burn QA, Dev, and BA time understanding the observed behavior that would not exist if we had closed out the story properly.
Solution – Keep Test Cases to a Single Story for a Simple and Natural Flow
Accepting stories (and points) only on the QA demo removes the vast majority of these trip hazards. The deliverable is more thoroughly vetted, and product owners see the flow as it would naturally occur. The behavior of a story is much better understood before future stories are defined and developed. As a bonus, identifying test cases to a single story is vastly simpler when revisiting them during the regression of stabilization or UAT.
Shortcuts Always Cost More in the End
Points are there for a reason. They motivate us to close stories. Use that urge to push hard to only close stories on a QA demo. The verbal promises that testing will go fine is not worth the paper it’s written on. Don’t take the points until the story is demo’d by the QA because shortcuts are more often the expensive road.
Randy Wagner is Director of Quality Assurance for CastleBay Companies. He has 20 years of consulting experience across private and public sectors, Guidewire InsuranceSuite, InsuranceNow, and Duck Creek, with specializations in quality assurance, configuration management, and automation.