TL;DR — The best refined stories of mice and men sometimes go awry. This includes dealing with stories sized with the best of intentions.
I’m often intrigued — and sometimes amused — by broad and definitive proclamations made on behalf of the Agile manifesto. The following blog post showing up in my LinkedIn news feed being an example I’d like to briefly discuss.
Without repeating the entire article, my takeaway is that the authors feel it is very, very bad to split an unfinished product backlog item (PBI) for the following reasons:
- Violates scrum;
- Compromises quality;
- Makes points useless; and
- Is all carrot, but no stick!
Potentially yes, any or all of the 4 maladies listed above could afflict a team splitting a user story … especially if it’s simply done so to massage the velocity at the end of a failed sprint.
That said, I would assert that any or all of the four aforementioned ailments have just as much potential to plague a team that decides to keep the story in tact.
Trust them to get the job done
First, I suspect that teams in the habit of gaming the system will continue to find ways to do so regardless of whether a PBI was originally sized properly, split, or kept in its original state.
Second, it’s been my experience that highly functional sprint teams generally don’t need to be told to have conversations about undersized PBIs; nor do they usually wait until a retrospective to dialog on such.
Similarly, I’ve observed strong teams show their maturity in not only addressing an undersized ticket, but they also seek to improve the process … usually in a fashion inspired by this little snippet found in the ‘Principles behind the Agile Manifesto.’
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Responding to Change
While it is important for a product manager — and the teams they serve — to take steps to avoid splittable PBIs making it into the sprint, it is equally important the team figure out how to deal with discoveries made early in the sprint that call into question an otherwise well-sized story.
And while I am no Richard Lawrence (see the above diagram), I’ve survived this situation enough times (early in the sprint) to suggest considering the following responses to change:
- Make a mandatory topic of the next retrospective a discussion of the original PBI.
- The original story should be cloned, as this will help retain linkage and a history of both items in systems such as JIRA and VSTS.
- Modify both stories, adhering as much as possible to INVEST principles; especially where dependencies can be avoided.
- Take time to carefully refactor the acceptance criteria of both stories.
- Resize both stories, and keep them in the current sprint. If their combined score is higher than the original, then other work not yet started and of a lower priority should be considered for removal from the sprint.
The idea is engaging points 2 thru 4 above as a guard against incomplete completion of stories. Point 5 and 1 serve as a means of keeping velocity real and relevant, forcing introspection to avoid similar sizing misses moving forward.
Now whether you agree with my recommendations or not, the larger point here is that without a processes that deals with in-flight learning — and responds to change (ahem) — not splitting a product backlog item is potentially as harmful as splitting it.
And as I inferred earlier, while a good product owner would want to split such stories before it gets refined … let alone pulled into a sprint … learning is messy, and doesn’t always conveniently occur before an estimation. So let’s figure out responses to instances of learning that occurs early in the sprint process.
p.s. If you disagree with this, or perhaps have additional recommendations, I’d love it if you’d drop us a comment to further this conversation. Don’t be shy!