INVEST In Product Backlog Refinement
Agile Requirements
Agile requirements are typically written as user stories and held in a Product Backlog that is continually being updated to add, amend or remove user stories. Defects may also be included in the Product Backlog. This on-going work, known as Product Backlog Refinement, is led by the Product Owner, supported by their business colleagues and stakeholders, as well as by project team business analysts and architects. This work occurs up-stream of development activities to fuel a pipeline of work for development.
The Product Owner, deemed to be the formal owner of the Product Backlog, is responsible for ranking the Product Backlog items in priority order of value, the most valuable coming first, least valuable last.
Populating The Sprint Backlog
Scrum teams take their work at the start of a sprint from the top of the Product Backlog into the Sprint Backlog. The Sprint Planning activity determines how many items can reasonably be moved into the Sprint Backlog that the development team can confidently commit to implement within the sprint.
It is good Scrum etiquette to cease from amending the user stories in question once they have moved into the Sprint Backlog although most teams will accommodate minor changes, at least up until the point that work actually starts on an item, if the changes do not materially impact on the earlier Sprint Planning.
Story Readiness
At any time, the Product Backlog will likely contain user stories in a variety of states of readiness. Some may be well defined and ready for implementation (meeting the development team's Definition of Ready), others may be vague and in need of further refinement by the Product Owner and/or development team.
The just-in-time philosophy of Agile means that only the user stories ranked towards the top end of the Product Backlog truly need to be in a state of readiness as lower ranked stories may never actually be implemented due to changing business needs or priorities.
We try to have a least two sprints worth of stories in a state of readiness at any time which gives us some buffer space when requirements are delayed, perhaps awaiting discussion and pending business decisions.
Definition Of Ready
Maintaining and applying a "Definition of Ready" by which the development team can evaluate and determine if a user story is ready for implementation or not is a recommended best practice and should be considered a "must have" by development teams.
It is essential that development teams evaluate and work to advance story readiness before taking stories into a sprint. Some degree of iteration between the up-stream Product Owner, business analysts and architects and the down-stream development team to further refine, clarify and break down requirements is to be expected before stories will eventually achieve the "ready" status.
For this reason, the development team should also perform Product Backlog Refinement, not just to confirm story readiness but to further breakdown user stories into smaller pieces of work where necessary and to clarify understanding and identify any potential issues from a development perspective prior to implementation.
Development Team Product Backlog Refinement
Product Backlog Refinement is an on-going activity for development teams alongside other sprint activities. The extent to which you invest in the process can have a massive impact on your work, especially when you architect for success and choose to apply the INVEST acronym to validate your user stories as part of your Definition Of Ready.
Teams should typically expect to spend around 10% of their time on Product Backlog Refinement per sprint. Each of our scrum teams typically performs three refinement sessions per two-week sprint, two in the first week and the other in the second week as we close out the sprint. Note this occurs after the up-stream Product Owner, business analysts and architects hand over stories that they believe are now ready to be evaluated by the development team.
Insufficient refinement by the development team can lead to inadequately defined user stories entering a sprint. (Under such circumstances, if you are lucky, you may be able to reduce the scope of your sprint and recover but if not, you may impact delivery timescales and the quality of your product. 😒)
Including Product Backlog Refinement activities in your Sprint Plan can help ensure that sufficient time is allocated for the development team to ensure this important process does not get overlooked. 😊
I.N.V.E.S.T.
A further enhancement to your Product Backlog Refinement activities is to apply the INVEST acronym to each user story as part of your process which acts as a helpful reminder of the guidelines for writing effective user stories. (Many teams incorporate this technique as part of their Definition Of Ready.)
According to the INVEST acronym, a good user story is: Independent, Negotiable, Valuable, Estimable, Small and Testable. (You can read about INVEST and find tips on writing effective user stories here.)
Independent
It is desirable for user stories to be independent of each other so that they can be implemented in any order. Dependencies between user stories (or on other teams), especially if discovered late, can de-rail your sprint and therefore need to be identified early and either avoided or carefully managed. (Product Backlog Refinement is the likely time that a dependency will be discovered.)
Negotiable
The scope of a user story should be negotiable between the developers and the customer so as to prevent unrealistic constraints on the feature or functionality.
Valuable
User stories should deliver something valuable to the customer or end users. The "so that" portion of the high level user story statement typically expresses the business value in an easy to understand way. If the business value cannot be clearly expressed then the story may need to be relegated in favour of something clearly more valuable.
Estimable
A good story can be estimated. If a story is not suitably understood, the size of the story and the likely effort to implement and test it will be indeterminate, making it challenging to schedule. The development team thus need to be sufficiently happy with their understanding of a user story in order to perform Planning Poker to obtain a story point estimate for the story which is often one of the requirements to meet the Definition Of Ready.
Small - Splitting Large User Stories
Although the definition of a user story (as compared to an epic user story) means it must be small enough to implement within a single sprint, it can be advantageous to further split a user story into even smaller stories in order to ensure all functional and non-functional aspects of your product features can be fully addressed individually without undue time pressures. (This is helpful so long as the approach does not prevent the development team from creating a Potentionally Shippable Product Increment at the end of each sprint.)
A helpful rule of thumb is that no story should be bigger than half a sprint.
Testable
A good story can be tested. Sufficient consideration must be applied to understand exactly how a story will be tested and the likely supporting activities involved in order to do so. Different approaches may be considered depending on the functional and non-functional nature of the story under test.
Asserting Architectural Influence
#AgileArchitecture
It's important for architects to be actively involved in the Product Backlog Refinement process, both in the early / on-going stages with the Product Owner (and business stakeholders) and in the latter stages with the development team.
Product Backlog Refinement sessions should be the regular haunt of Agile Architectss which present an essential opportunity to understand business objectives and to discuss and agree non-functional requirements that might otherwise not be prioritised or implemented.
Working this way, architects are able to create user stories to drive out the intentional architecture of the product prior to implementation, as well as guide the emerging architecture as the product is built incrementally through each iteration.
Architects should actively support the development team with technical design and in the identification of test approaches and test scenarios to ensure both functional and non-functional requirements are met and to also ensure that the emerging architecture is in alignment with the intentional architecture.
Without the up-stream knowledge of requirements (including key business objectives and concerns), it's impossible to plan ahead in terms of architecture. It's also impossible to shape the technical design "on the ground" with the development team without being involved in their Product Backlog Refinement sessions and daily work.
Architectural involvement often leads to the identification of spike activities for the development team which help lay the groundwork (what SAFe calls the "architectural runway") for the unfolding product architecture.
Architects also work with the development team to plan and execute proving activities such as performance and volume testing and security vulnerability assessments for example, to mitigate risks. (Such proving activities and technical spikes both start off as requirements on the Product Backlog.)
Along the way, the aim is to create just enough documentation to describe the key business objectives and the design decisions addressed by the architecture. This is "living documentation" that evolves, usually with lots of diagrams, that also includes details of risks / issues, assumptions, constraints and principles, that helps explain the rationale for the architecture with traceability back to the business objectives and the project vision.
The architecture documentation also describes key architectural concepts for the product that explain the "what and why of things" to assist new team members on-boarding onto your project.
Architecture is, and always has been, a key factor in the success of Agile projects and you can learn about Capgemini's approach to Agile IT Architecture known as the JIT JEA Way Of Working.
Reaping What You Sow
Ensuring the development team has a good understanding of the requirements for a sprint from the outset is common sense and the way to achieve that is through regular Product Backlog Refinement sessions prior to the sprinting of user stories.
Performing Product Backlog Refinement as an up-front process will help the team identify issues early and gain valuable clarification of requirements. It will also enable a more detailed understanding of the likely work involved to implement them ahead of sprints starting.
Applying the INVEST acronym as part of the team's Definition Of Ready can help ensure all aspects of a story are fully assessed before a sprint leading to more accurate estimation and planning.
From my own experience with teams, Product Backlog Refinement sessions present a great opportunity to improve productivity and product quality, which both suffer when insufficient time is spent on this activity.
We witnessed a significant improvement in productivity over a three month period when we made Product Backlog Refinement so much more intentional for our scrum teams and adopted use of the INVEST acronym within our Definition Of Ready.
Agile Health Check - Product Backlog Refinement
Why not take the opportunity to give your Product Backlog Refinement an Agile health check?
#AgileHealthCheck
|
Healthy
|
|---|
|
Unhealthy
|
|
Thank you for liking this page.
Tim Simpson
25th February, 2022
#LifeAtCapgemini