To meet schedules, deliver valuable products, and exceed your stakeholder’s expectations, you need the ability to flex scope and offer an actual minimum marketable product. You need to know how to break down your work to be forced by technology or business processes to deliver anything more than the minimum.
Yet something in agile seems to be missing: the MVP is devilishly elusive because leadership sets due dates and staffing, but flexing scope is nearly impossible. All functionality becomes part of the minimum, and the MVP becomes the first release. Any subsequent releases become minor enhancements or patches. The product is never in the customers’ hands until many sprints have passed, and the product is fully functional, handles the majority of customer needs, and is well polished.
This post is part of a series on ways to split work items so that a minimum viable product becomes minimum, not maximum. I’ll be using stories I picked up from the internet.
In some cases, splitting a PBI will not evolve the system, only complicate the product backlog. For example, when signing up for a newsletter, US customers and customers from Guam may have precisely the same information layout and processing, just different country codes (data). A split by country in such a case wouldn’t help. So take the advice given here as a tool to be used when it makes sense.
The most straightforward step to take: disambiguate the PBI by just looking at the wording. Break out your English book from grade school. You’re going to need it.
The first step is to look for conjunctions (and, but, or) and try to break the PBI at these points. Sometimes you’ll have to reword the PBIs, but this is an easy point to start.
Original
Refactored:
In the above example, the full functionality may or may be released with HR or HRT. Perhaps rejecting isn’t as crucial as approving, so a release can be created without rejection functionality. Concentrating on only HRTs at first may provide a lot of insight when the team moves on to HRT to applicants. It may be possible only to implement the capability to read HRT and HR applications. Without this kind of split, a lot of flexibility is not available to the business.
Look for adjectives and adverbs. Can you substitute different adjectives or adverbs to make the PBI simpler or approach the need from a different perspective? For example, for “student credit card,” you could substitute student with general, high leverage, low risk, high risk, business, family. “Quickly” can be replaced with “slowly” or other adverbs to split the work. Grab a thesaurus!
Original
Refactored to add more richness:
Look at nouns in the PBI. Are there other nouns that can be used to make the PBI split or more precise? Again a thesaurus can help. Customers can be patron, client, purchaser, buyer, end-user, shopper.
Using some nouns can be unclear. For example, is a customer looking at your e-commerce website, one who sets up an account, or one who purchases (with or without an account)? Can you have a customer that hasn’t even looked at your website? Can a customer be one who hasn’t made the purchase but is using the product as someone else purchased it for them?
Original
Refactored to add more richness:
There you have it: splitting by looking at the semantics. It seems simple but if you keep your eyes open you will see plenty of opportunities to split PBIs based on this simple technique.
I’ll be providing additional ways to split PBIs in other articles.
-Dr. Chuck
Source: https://www.scrum.org/resources/blog/backlog-refinement-techniques-part-1-semantic-analysis
Get in touch
To be able to help we need to assess each project individually. Our free project assessment session will help us recommend the first steps you'd need to take to make scrum work for you.
Schedule a call