BACKLOG REFINEMENT MEETING

GROOMING MEETING

Backlog Refinement Reference Link

Most product backlog items (PBIs) initially needs refinement because they are too large and poorly understood.

The main purpose of a backlog refinement meeting is to make the PBI meet INVEST criteria.

I would like to call this more as an activity rather than a meeting.

Splitting of the product backlog into smaller pieces is known as backlog refinement or grooming.

This activity is facilitated by Scrum Master and team collaboratively works on it.

User Story: It constitutes of 3c’s: Card/Conversation/Confirmation

It captures a description of a software feature from an end-user perspective.

The user story describes the type of user, what they want and why.

A user story helps to create a simplified description of a requirement.

Grooming has 3 major activities

Prioritization > Slicing > Estimation

Backlog Refinement Meeting

  • Prioritization Technique
    • Value Stream Mapping
    • Moscow
    • Kano Model
    • Business Value Based
    • Technology Risk Based
    • 100 points

  • Slicing Technique
    • Horizontal Slicing
    • Vertical Slicing
      • Workflow
      • Happy / Unhappy flow
      • Business Rules
      • Platform
      • Datatype / Parameter
      • Operation (crud)
      • Roles
      • Test Scenario / Test Case
  • Estimation Technique
    • Planning Poker
    • T-Shirt Sizing
    • Relative Mass Valuation
    • Bucket System

Why do we Prioritize? Because we cannot work on everything at once.

Product backlog grooming or product backlog refinement: Determines and separate what needs to be done now, and what needs to be done later.

1.    PRIORITIZATION

The need to prioritize come from a very simple fact, we just don’t have enough resources to work on everything we can come up with.

Value Stream Mapping

Value Stream Mapping focuses on eliminating waste. Its main function is to categorize the work and identify the waste.

It visualizes the whole process from an idea to customer releases as a series of conceptual tasks.

Both value and non-value adding tasks should be defined and tracked from customer requirement to delivery.

You can easily identify waste in the system by looking at the holistic representation of your complete development cycle.

 MoSCOW model is based on the business value first.

It is a prioritization technique used in management, business analysis and project management to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.

  1. M – Must have – these requirements are critical therefore must be given 1st If even one of the requirement is not included in the project, the project is considered as a failure.
  2. S – Should have – these requirements are very important but not necessary for delivery in the current sprint / time box. Important but not critical. May be painful to leave out these items, but the solution is viable.
  3. C – Could have – these requirements are desirable but not necessary
  • Wanted or desirable but less important
  • Less impact if we leave out these requirements
    1. W – Won’t have – these requirements are agreed by stakeholders that it’s least critical
  • Project does not deliver these requirements

Example HR System

  1. Must – store leave history of an employee
  2. Should – search and send notification
  3. Could – automated notification
  4. Won’t – remote access to the system

Kano Model

It is based on customer satisfaction.

When to use to model?
When there’s less time, this model will help the team to evaluate the features of a potential product.

  1. Basic (Must-be) Quality
  • Simply stated, these are the requirements that the customers expect and are taken for granted. When done well, customers are just neutral, but when done poorly, customers are very dissatisfied.

    2. Performance Quality

  • These attributes result in satisfaction when fulfilled and dissatisfaction when not fulfilled.
  • These are attributes that are spoken and the ones in which companies compete.

Example: A milk package that is said to have ten percent more milk for the same price will result in customer satisfaction, but if it only contains six percent then the customer will feel misled and it will lead to dissatisfaction.

3. Attractive Quality (wow)

These attributes provide satisfaction when achieved fully, but do not cause dissatisfaction when not fulfilled. These are attributes that are not normally expected.

For example, a thermometer on a package of milk showing the temperature of the milk. Since these types of attributes of quality unexpectedly delight customers, they are often unspoken.

4. Indifferent Quality 

These attributes refer to aspects that are neither good nor bad, and they do not result in either customer satisfaction or customer dissatisfaction.

For example, the thickness of the wax coating on a milk carton. This might be key to the design and manufacturing of the carton, but consumers are not even aware of the distinction.

5. Reverse Quality 

Sometimes too many features also lead to dissatisfaction.

All the requirements are placed on a chart with execution on X axis & satisfaction on the Y axis.

Business Value Based

  • Product owner takes all the requirements from the customers and writes them in the form of user stories with the help of scrum team.
  • Here, each user story carries a business value it could potentially generate.
  • One with the highest business value is given higher priority.
  • Three main factors are considered
    1. Value
    2. Risk or uncertainty
  • Dependencies

Technology Risk Based

  • In this method, requirements are prioritized based on the risk associated with implementing it.
  • The risk is typically based on the technology. The requirement with highest technology risk is implemented during the earlier iterations.

 

100-Point Method

It involves giving the team members 100 points so that they can use to vote for the User Stories that they think are most important. The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories. Each group member allocates points to the various User Stories, giving more points to those they feel are more important. On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story.

Walking Skeleton

  • A walking skeleton is a tiny implementation of the system that performs a small end-to-end function.
  • It need not use the final architecture, but it should link together the main architectural components.
  • The architecture and functionality can then evolve in parallel.

2.    SLICING

Horizontal Slicing

It involves breaking user stories by application layer like UI, Databases, Front-end, Backend & Testing.

This approach is typically used in traditional (water) development model but it’s not recommended in the scrum because:

 – Individual items do not provide business value until integrated

 – Does not promote self-organizing / cross functional

 – Increase bottleneck, instead of reducing them

 – The technical item would be difficult to prioritize as PO would find it difficult to determine value.

Vertical Slicing

Here we split the user stories by functional layer rather than application layer

If a user story is split vertically, it is split in such a manner that the smaller items still generate some business value. The functionality will not be split across technical layer or tasks but across functional layers.

There are different strategies for vertical slicing

  1. Split by Workflow

If user stories involve a workflow of some kind then the item can usually be broken up into individual steps:

Example: As customer, I want to purchase the goods in my shopping basket so that I can receive my products at home

  • As customer, I want to log in with my account so I don’t have to re-enter my personal information every time;
  • As customer, I want to review and confirm my order so, I can correct mistakes before I pay;
  • As customer, I want to pay for my order with a wire transfer, so that I can confirm my order;
  1. Split by Happy / Unhappy flow

Functionality often involves a happy flow and one or more unhappy flows.

The happy flow describes how functionality behaves when everything goes well. 

If there are derivations, exceptions or other problems, unhappy flows are invoked.

As customer, I want to log in with my account so that I can access secured pages;

  • As user, I want to log in with my account, so that I can access secure pages (happy);
  • As user, I want to be able to reset my password when my login fails so I can try to log in again (unhappy);
  • As user, I want to be given the option to register a new account if my login is not known so I can gain access to secure pages (unhappy);
  • As site owner, I want to block users that log in incorrectly three times in a row so I can protect the site against hackers (unhappy);
  1. Split by Business Rules

Many user stories involve many explicit or implicit business rules. Take this user story, again for the order process of a regular web shop:

As customer, I want to purchase the goods in my shopping basket so that I can receive my products at home

  • As shop owner, I want to decline orders below 10 dollars, because I don’t make any profit on them;
  • As shop owner, I want to decline customers from outside the US, because the shipping expenses make these orders unprofitable;
  • As shop owner, I want to reserve ordered products from stock for 48 hours, so other customers see a realistic stock;
  1. Split by platform / input options

Many web applications should support various input options and/or platforms, like desktops, tablets, mobile phones or touch screens.

As team member, I want to view the Scrum Board, so I know the status of the sprint

  • As team member, I want to view the Scrum Board on my desktop, so I know the status of the sprint;
  • As team member, I want to view the Scrum Board on my mobile phone, so I know the status of the sprint;
  • As team member, I want to view the Scrum Board on a touchscreen, so I know the status of the sprint;
  1. Split by data type or parameters

Some user stories can be split based on the data types they return or the parameters they are supposed to handle.

As customer, I want to search for products so I can view and order them

  • As customer, I want to search for a product by its product number, so I can quickly find a product that I already know;
  • As customer, I want to search for products in a price range, so that the search results are more relevant;
  • As customer, I want to search for products by their colour, so that the search results are more relevant;
  1. Split by Operation

User stories often involve many default operations, such as Create, Read, Update or Deleted (commonly abbreviated as CRUD). CRUD operations are very prevalent when functionality involves the management of entities, such as products, users or orders.

As shop owner, I want to manage products in my web shop so I can update price and product information if it is changed

  • As shop owner, I want to add new products, so customers can purchase them;
  • As shop owner, I want to update existing products so I can adjust for changes in pricing or product information;
  • As shop owner, I want to delete products so I can remove products that I no longer stock;
  1. Split by Test Scenario / Test Case

This strategy is useful when it is hard to break down large user stories based on functionality alone.

In that case, it helps to ask how a piece of functionality is going to be tested. Which scenarios must be checked to know if the functionality works?

As manager, I want to assign tasks to employees so they can work on tasks

  • Test case 1: If an employee is already assigned, he or she cannot be assigned to another task;
  • Test case 2: If an employee has reported in sick, he or she should be visually marked so they can be ignored;
  • Test case 3: If an employee has reported in sick, he or she cannot be assigned to a task;
  1. Split by Roles

User stories often involve a number of roles (or groups) that performs parts of that functionality. Take a user story to publish new articles to a public newspaper website.

As news organization, I want to publish new articles on our homepage, so customers have a reason to return periodically

  • As customer, I want to read a new article so I can be informed of important events;
  • As journalist, I want to write an article so it can be read by our customers;
  • As editor, I want to review the article before putting it on the site, so that we can prevent typos;
  • As admin, I want to be able to remove articles from the site, so that we can pull offending articles;

3.    ESTIMATION

Estimation is not a confirmation.

Estimates are done by the team in the presence of the PO and not by the PO himself because he is not the one doing the work. Don’t under estimate or over estimate. Underestimation is more dangerous.

Estimation Technique Reference Link

The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items.

Estimating user stories is done in days.
Estimating task is done in hours.

Estimation is done in story points basing on:

    • Amount of work
    • Complexity
    • Risk or Uncertainty
    • External factors

Planning Poker

  • Most widely used.
  • Better when the team knows about the estimation
  • Better to use when there are fewer user stories (10-20)

How it is done –

  • Most popular and most widely used estimation technique
  1. Each estimator is given a set of cards containing numbers to be used for estimation (generally Fibonacci series or doubling the number)
  2. PO reads the user story and it’s discussed briefly
  3. Each estimator selects a card that’s his or her estimate
  4. Cards are turned at the same time
  5. Outliers will discuss their views and again everyone will pick up a card.
  6. Process continues until all the estimators reaches on a consensus

T-Shirt Sizing

  • Used when the team is new to Scrum.

How it is done –

  • Here user stories efforts are estimated using different t-shirt size (xs, s, m, l, xl)
  • When the team is not able to decide on exact number it would be effective to switch to non-numerical t-shirt sizing
  • Non-numerical scale is less granular
  • Even though they are speeding up the process they can decrease the accuracy level
  • It also requires extra effort as the t-shirt size needs to be converted into numerical value for the sake of tracking efforts & velocity chart.

Relative Mass Valuation

  • When there are more user stories to estimate (more than 50-150)

How it is done –

  • Relative mass valuation is a quick way to go through a large backlog of stories and estimate them relative to each other
  • First, write up a card for each user story
  • Then set it up on a large table
  • Pick any story to start and get the team to estimate whether they think that it is relatively large, medium or small (large on the rightmost corner, medium in between and small in the leftmost corner)
  • Pick another story and arrange it accordingly relative to the last card
  • Next step is to assigning points to the stories
  • Starting from least complex story assign 1 to every story until you find a story that is twice as complex and assign 2 and continue the process for remaining of the cards

Bucket System

  • The bucket system is a way to quickly estimate large number of item with a small to medium sized team
  • The bucket system works as follow
  • Set up the physical environment by arranging the buckets in a size wise order and assign a number to the bucket for example 1 to the smallest bucket 2 to the little bigger bucket and so on (usually numbering we follow is 1,2,3,4,5,8,13,20,30,50,100,200).
  • Choose an item at random and read it to the group and place it in the middle bucket
  • Choose another item at random and after discussion and reaching consensus place it in its appropriate bucket
  • Choose 3rd item at random and again discuss it, reach consensus and place it in its appropriate bucket
  • If the random item has clearly skewed the scale towards one end or the another, we re-scale the item. E.g. if the 1st item is actually very small.