Sprint grooming/ refinement meeting’s objective is to make the stories ready to be picked by the engineers for implementation. In this article, we will talk about various aspects of this meeting and TPM role in it.
Meeting Participants:
Sprint grooming meeting is attended by Product owner, Scrum Master (usually TPM) and Engineers. Occasionally, business analysts, architects etc. can also be invited based on their domain expertise and knowledge of other dependent systems.
User Story Writing:
Ideally, Product owner/PdM should be writing the user stories but the reality is different. Technical user stories like architectural improvements or operational user stories for monitoring etc. will need to be added by engineers or TPM. In practice, any one should be able to add a user story to the backlog. Most teams have a high-level division of the sprint/iteration like 60:40 or 70:30 for business user stories and technical user stories. Let’s take an example, if your team has 50 story point velocity then following the 70:30 model, it will be 35 business user story points and 15 technical user story points. Please note that while calculating capacity, about 15 to 20 % of team capacity may need to be reserved for production support/on call support and incident management. The remaining 85 to 80 percent capacity will be assigned to the business and tech user stories.
Many teams also maintain separate projects in ALM (Agile Life-cycle Management) like JIRA for Business user stories and Technical user stories. TPM is responsible for converting Business User Stories into technical user Stories and create a ‘technical’ user story backlog. TPM can setup a meeting with the engineers, go over business user stories and come up with all the technical user stories needed to implement the business stories.
In general, engineers and operations resources are reluctant to add user stories to the repository. This is a great opportunity for a TPM to add value. Get the content from the engineers and others as needed and create user stories. It’s OK if the story doesn’t have lot of details or acceptance criteria, that can be added as part of the grooming.
The bottom line is that as a TPM you want as much participation and contribution at each stage of the project as possible. Although, you will be doing lot of coordination and facilitating in your role, you do not want to be labeled as a pure coordinator or an admin. The more involved you are in writing user stories, getting them groomed, acceptance criteria clarification and management of dependencies the better.
User Story Conversation:
Product Owner or TPM presents the stories to the Engineers/attendees. All the attendees, specifically engineers ask clarifying questions and add any missing details are added to the User Story. Every User Story needs to have clear acceptance criteria. You can use INVEST checklist against a user story to measure its completeness. INVEST stands for
“I” ndependent (of all others)
The story needs to be independent of other stories in the backlog. If this story is so tightly connected with another story that both must go together in a single sprint, then these two should probably be combined to make one story.
“N” egotiable (not a specific contract for features)
A story is like an invitation to a conversation. The purpose of this conversation is to understand the spirit behind it rather than going word by word as if it’s a legal contract. The idea is to continue ‘negotiating’ until all come to an understanding of the story that will add some value to the customer. It’s not the letter of the story but the spirit behind the story which is important.
“V” aluable (or vertical)
A story should add value to the customer. It is also a small vertical piece like a piece of cake which has all layers in it e.g. its ok to deliver 1 text box on a webpage which receives the input, connects to a database, applies some business rules and show a meaningful result, rather than having five dumb textboxes on the page which do not do anything.
“E” stimable (to a good approximation)
“S” mall (so as to fit within an iteration)
“T” estable (in principle, even if there isn’t a test for it yet)
Do not invest half of the meeting making one user story INVEST compliant as it can derail the meeting entirely. This is just a guideline to make sure story adds value and is deliverable within the sprint.
User Story Pointing:
Once the story’s scope and complexity has been understood by engineers its is ready to be ‘pointed’. Fibonacci series is a widely used technique. Below table gives a high-level idea on how points translate to ‘T’ shirt sizing.
1 – XS
2 – S
3 – M
5 – L
8 – XL
13 – XXL
Team can decide an XS story standard and then use it as a measurement yardstick for other stories.
For example, team can decide that creating a textbox on a webpage which can receive an input and save it to the database is 1 story point, now any story can be pointed based on the relative complexity to this definition.
After the user story is discussed, all the engineers will individually propose number of story points for a story. Team can take an average of story points proposed and assign to the story. If there is significant difference in proposed story points e.g. one person feels it’s a 3 points story while another one has given it 8 or 13 then both should provide details on why they think so and story can be repointed. This story can be marked as groomed and Product owner can rank it relative to other stories in the groomed list of stories.
Many times, story owners can also be assigned to the User story at this time. A user story owner is not necessarily the person who will do all the work on the story. There may be multiple tasks and resources associated with one story. A user story owner helps in leading and coordinating the tasks and getting the story delivered.
TPM Role in Grooming:
The most important role of the TPM in backlog grooming meeting is to set it up and conduct it regularly. Occasionally, this meeting gets dropped from the calendar due to a variety of reasons like; engineers too busy in current sprint and product owner not ready with stories etc. Do not let it fall off the calendar! Meeting should be conducted regularly even if its short and meeting minutes should be shared within the team and management including Engineering Manager, Product Owner Manager and TPM manager. The minutes should include how many user stories were considered for grooming, how many were groomed and how many postponed along with the reasons of postponement and any follow ups being done.
Meeting Frequency:
Frequently of this meeting depends on sprint velocity, backlog health objective and number of story points groomed per meeting. Suppose your team’s velocity is 20 points per sprint and your backlog health goal is 2X the velocity. This means that your backlog should have 40 groomed stories at any time. Now, if your team grooms 10 story points per meeting, it shows that initially you will need 4 or more meetings to reach the backlog health objective and later on 2 grooming meetings per sprint.
Leave A Comment