top of page
  • Writer's pictureValentina Zanetti

Distilling Value from the Product Backlog

How to create and maintain a high-quality Product Backlog that generates real value to the users and the company!


Product Backlog

Your Product Backlog is the spine of your digital product. It's a map and a recipe book all in one, and it dictates the outcome of the product. So needless to say, it's crucial that it's well-written and well maintained, in order to maximize the product value.


Start from the Top of Your Product Backlog


𝐓𝐡𝐞 𝐏𝐚𝐫𝐞𝐭𝐨 𝐩𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 states that for many outcomes, roughly 80% of consequences come from 20% of causes (the "vital few"). Grooming the backlog effectively means identifying the 20% of causes that will yield you the most value and focusing most of your efforts on those implementations.


How to identify the 20% most relevant implementations?


🔸The focus should be on the Product Vision and Goal. What is the product trying to achieve? What is your core user journey, from start to finish? What are the main segments of the core user journey?


🔸Who are your users? What are their personas like and how do they usually behave in the digital world? Do they have vastly different habits or are their browsing preferences similar? What has been proven as an effective way to trigger a desired behavior in your user personas? Will their user journeys be similar or very different?


🔸How do you plan to illicit the desired behavior in the defined user groups? What is the optimum route to facilitate the core user journey for each user persona? How would you create a better experience for them? What additional features could the product have to enhance the user journey for each persona?


🔸How would the success be measured? And which tools would be used to collect and store data? Would this information be easily digestible for stakeholders?


When you have this information identified, it should be divided into epics, or high level groups that will contain more specific user stories. Whether you want to divide them by business value, systems interaction, or by steps in the path is up to the team, the conditions of the product and your general practices and culture. The epics can also always be reorganized to make more sense as you go along, but always keep in mind that they need to directly align with product goals and company initiatives.


How to Write Great User Stories that Align with your Epics and Product Goals


Creating User Stories is much more art than it is science, and although the Product Owner can provide a rough outline, the User Stories should be created by the whole team together.


User Stories should have a simple description, consisting of one sentence:


"As a [User Persona], I want to [perform an action], so that [I can achieve this outcome]"


In this simple sentence, you have identified the user persona the story pertains to, what is the action they should perform, and - most importantly - the reason behind the action, 𝐭𝐡𝐞 𝐮𝐬𝐞𝐫'𝐬 𝐦𝐨𝐭𝐢𝐯𝐚𝐭𝐢𝐨𝐧. You can also flip the sentence around for even greater emphasis on the goal, so it goes like this: "So that I can [achieve this outcome] as a [User Persona] I want to [perform an action].


Most of this information is already identified in the Epics, and there are many methods and techniques that can be used to split Epics into User Stories, such as:

🔹The 'and', 'but' or 'or' technique

🔹Splitting by Incremental Business Value Delivery

🔹Splitting by User Roles

🔹Splitting by Acceptance Criteria

🔹Splitting by Data

🔹Splitting by Business Rules

🔹Splitting by Workflow Steps

🔹Splitting by Use Case Paths


Whichever technique you choose, for a User Story to be valuable you must also take the following into consideration:

🔸Each story should be small enough to be completed during a sprint, but not so small as to serve as a single task

🔸Each story should be split as vertically as possible and include as many if not all product development aspects

🔸Each story should result in a standalone deliverable that can meet the Definition of Done, be tested, and integrated with other deliverables

🔸Each story should have a desired impact on user behavior, some action it is aimed to elicit or deter from

🔸Each story must have a purpose, and 𝐭𝐡𝐞 𝐠𝐨𝐚𝐥 𝐨𝐟 𝐞𝐚𝐜𝐡 𝐬𝐭𝐨𝐫𝐲 𝐦𝐮𝐬𝐭 𝐛𝐞 𝐚𝐥𝐢𝐠𝐧𝐞𝐝 𝐰𝐢𝐭𝐡 𝐭𝐡𝐞 𝐠𝐨𝐚𝐥 𝐨𝐟 𝐭𝐡𝐞 𝐄𝐩𝐢𝐜 𝐚𝐧𝐝 𝐭𝐡𝐞 𝐠𝐨𝐚𝐥 𝐨𝐟 𝐭𝐡𝐞 𝐩𝐫𝐨𝐝𝐮𝐜𝐭, otherwise it is just waste


The created User Stories and their corresponding descriptions are, alas, not enough to start performing work on them immediately, so in addition to a quality description you'll also need the following:

💠Design guidelines (preferably not a design specification, and collaboration with the designer remains open to optimize the output)

💠Acceptance criteria, created together by the whole team along with the Product Owner

💠Technical specification, if it cannot be conflated with the acceptance criteria, created by the development team

💠Unit tests, preferably before the start of development and preferably automated, created by the development team and QA specialists


Creating purposeful, well thought-out and high quality User Stories is a process that requires refining and improvement, like all agile processes. Don't forget to discuss this in your team's Retrospectives!


Refining Your Product Backlog


How frequently should you refine your Backlog and your User Stories?

The answer is, as frequently as possible, sometimes multiple times a day.


Somewhere along the line, many people have equated backlog refinement with a formal event where the team gets together with the specific purpose to refine the Backlog and the User Stories, and there's an implication that this is only done during this event.


But the Scrum Guide itself states:

"Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. 𝐓𝐡𝐢𝐬 𝐢𝐬 𝐚𝐧 𝐨𝐧𝐠𝐨𝐢𝐧𝐠 𝐚𝐜𝐭𝐢𝐯𝐢𝐭𝐲 𝐭𝐨 𝐚𝐝𝐝 𝐝𝐞𝐭𝐚𝐢𝐥𝐬, 𝐬𝐮𝐜𝐡 𝐚𝐬 𝐚 𝐝𝐞𝐬𝐜𝐫𝐢𝐩𝐭𝐢𝐨𝐧, 𝐨𝐫𝐝𝐞𝐫, 𝐚𝐧𝐝 𝐬𝐢𝐳𝐞."


Backlog refinement isn't a single event or a single meeting. It is a series of continuous efforts, both synchronous and asynchronous, performed by the entire team and other stakeholders, using multiple tools, with the purpose of gaining clarity on the goals and discovering ways how to best achieve them.


It is not and never should be treated as a single event, much less as a requirements hand-off, which we still see much too often. Try to avoid this trap at all costs.


Each story (as everything else in the backlog) is negotiable and up for discussion by the whole team:

🔸Is the story itself still relevant, and if so, does the team still believe it will bring value to the product?

🔸Can the acceptance criteria be improved and does it align well with the purpose of the story, and subsequently the epic and product goal?

🔸Is the design technically feasible? Is it overly complicated and if so, can it be simplified without compromising the story goal?

🔸Is the technical specification the best it could be? Are there better ways of achieving the goal?

🔸Are the unit tests reliable and up-to-date with the acceptance criteria and technical specification? Can they be improved and expanded to provide better test coverage?

🔸Will the deliverable be integrable with other deliverables and the product? Do any of the stories' technical specifications hinder or prevent this?


Yes, a healthy backlog requires a lot of attention. And your team will oftentimes need to align multiple times a day, during formal meetings, during ad-hoc calls, over chats, documentation, Miro boards and Jira (or whatever you use).


Now, this is not to say that formal refinement events aren't useful and oftentimes necessary. It's to say that they aren't enough.


The Definition of Done and Why it's Important


Per the Scrum Guide, the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.


The DoD is created by the whole product team and relevant stakeholders by reaching a consensus on what 'Done' means. It is basically a criteria for each increment to be considered potentially shippable.


It is, however, the commitment and responsibility of the cross-functional team to get each increment to the 'Done' state. It provides transparency on what it means to have an increment completed, and allows alignment on the level of quality that should be delivered, especially if there are multiple teams working on the same product.


It is not to be confused with the Acceptance Criteria that is different for each story. The DoD is on overarching checklist of criterion that every story needs to meet in order to be considered finished.


It can have some of the following criteria, oftentimes more (usability, accessibility, security, organizational policy, legislation and regulatory compliance...):

🔹Unit test passed

🔹Code reviewed

🔹Acceptance criteria for each issue met

🔹Functional tests passed

🔹Non-functional requirements met

🔹Product owner accepts the increment


And like any other element in agility, it is susceptible to change and refinement.


However, when changing your DoD, take the following into consideration:

🔸Don't weaken your Definition of Done, it's a symptom of avoiding dysfunction instead of dealing with it head-on, and a symptom of lowered quality

🔸Strengthening your DoD and increasing the list of criteria is welcomed, as long as it doesn't jeopardize the Sprint or Product Goals.

🔸Changing your DoD mid-sprint is OK but endangering the Sprint Goal or the Sprint Goal of any other teams working on the same product should be avoided, if possible. Of course, if there are new regulatory requirements or new legislation that has emerged, the updated DoD must be taken into consideration.

🔸It's advisable to make changes to the DoD at Sprint Boundaries. The Retrospective is a formal event when this can be done, so be sure to include the DoD in the agenda every so often.


And remember, the Definition of Done isn't meant to demand perfection, it's meant to provide transparency about what is 'good enough' to be potentially shippable and maximize the work not done and it's meant to shed light on potential process and/or team dysfunctions.


Conclusion


A well groomed backlog is of critical importance. Dedicating enough time to its refinement and improvement will save a lot of failed experiments, stakeholder and/or end-user dissatisfaction and a lot of misguided development.


And while the backlog is the primary responsibility of the Product Owner, that is not to say that the whole team and other stakeholders cannot participate in its creation as well as its refinement. The more aligned the team is around the backlog, the better the end-results will be.


For more questions about creating a stellar backlog and more, don't hesitate to reach out to us at coven@agile-alchemists.com and subscribe to our Newsletter to get the goodies directly to your inbox!

114 views0 comments

Recent Posts

See All

コメント


bottom of page