Product Backlog Refinement, is a method for keeping the backlog updated, clean and orderly and held near the end of one sprint to ensure the backlog is ready for the next sprint. We should do a 1-hour backlog refinement meeting on day 4 and day 8 (assuming that it is a 2 week sprint) with the onshore team(If applicable otherwise with the whole team), product owner, and scrum master. Without this practice, we would end up spending a lot of time grooming and deciding stories for the next sprint on Day 1 of the sprint.
Product backlog grooming/refinement
Responsible entity:- Product Owner
The expectation from Responsible Entity
Any queries /concern raised by the team during pre grooming sessions are addressed
Sprint Goals are set and discussed with the team.
Functional and Nonfunctional Requirements are addressed.
The acceptance criteria should be clearly explained to the team.
The PO ensures product backlog priority is up to date (At least top-level items) for the team to pick up items from the product backlog. The stories are picked up and prioritized. The PO usually talks about sprint goals and once that is finalized, the stories are picked up for grooming.
For each story, the product owner writes down the description of the story and acceptance criteria. While grooming it can be further updated by PO and team. The team gets answers for their queries from the PO with respect to functional expectations.
In addition to that, the team works together to identify
The team typically elaborate more on functional requirements as well. The stories are further broken down into multiple tasks during the Sprint Planning session.
Diagrammatic representation of Product Backlog Grooming
Example of a well-defined user story
Most of us have used net banking at some point in time and most of us use it day in and out. E.g downloading historical statements. There are certain specific options available for downloading them.
There is an option to select the type of file for downloading your statement.
There is an option to choose if you want to download only the Credits/Debit /both.
Now imagine that the Product Owner gives you this User story “As a customer, I want to download my account statement so that I can view all my transactions done for a specific period”.
With the following Acceptance Criteria:
Considering that I am on the Download Historical Statement Page, I should select the period for which I want to download the statement.
Considering that I am on the Download Historical Statement Page, I should select the account for which I want to download the statement.
Considering that I am on the Download Historical Statement Page, I should not be allowed to download the statement for future ‘To’ dates.
Considering that I am on the Download Historical Statement Page, I should not be allowed to select ‘From’ date 10 years beyond in the past.
Considering that I download my statement, I should be able to view the downloaded file.
Considering that I am on the Download Historical Statement Page, I should be able to download my statement in doc, excel, and pdf formats.
If you go through this acceptance, there are 3 things missing here:
Name and format of the file name that will be downloaded.
What information (Column names) is to be displayed in the file.
The options list to select what kind of a transaction the customer wants i.e. only debits or only credits or both.
The team should study well about each acceptance criteria and try to visualize it with reference to the user story. The more the team studies deeply about the conditions and business rules, there will be a gradual increase in knowledge about the feature.
Bugs found in the initial stage cost nothing compared to what it may cost in the ‘testing’ stage.