Meeting Archive

1

Cheat Sheet for Backlog Refinement

Backlog Refinement Meeting

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

  • (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal
  • (Optional) representative(s) from the Management Team – clarify the high level priorities
  • (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items
  • (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items.  It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

  • The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team
  • Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research
  • Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team. 

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Originally Posted at LeadingAgile

0

A Lack of a Shared Understanding

I am so glad we all agreeEarlier this week, I facilitated a backlog refinement meeting.  In the past, the team was used to all of the requirements being completed (in advance) by the analysts. The delivery team would then execute on those requirements. The problem, of course, was no shared understanding.

We came into the meeting with everyone agreeing they were on the same page.  That was true for about 15 minutes. The more we talked, the more they realized they were looking at things from individual perspectives.

At the beginning of the meeting, we had less than 10 user stories, from an analyst’s perspective. By the end of the meeting, we had a prioritized backlog with over 100 user stories at different levels of granularity.  It’s not perfect and it’s never done.  But, it’s a start.  For the first time, developers and testers were engaged at the beginning.  At LeadingAgile, we call this the Product Owner team.  When the highest priority stories get to a “ready” state, they will be pulled into a delivery team’s queue.  Until then, we need to answer some of the more complicated questions, mitigate risk, and achieve that shared understanding.

Image Source: Based on hand drawn image from Pictofigo

0

Free Sprint Planning Guide and Agenda

As part of an Agile assessment, I sat in on a sprint planning meeting.  Though many out there are having sprint planning meetings at the beginning of every sprint, are they getting the most out of the time and effort?  As part of the services to my client, I will be providing a free cheat sheet for sprint planning.  It is both a guide and an agenda, to help keep them focused.  If you want a copy, just click the link at the bottom of the post.

What is Sprint Planning?
The purpose of the sprint planning meeting is for the team to agree to complete a set of the top-ordered product backlog items. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

Who Does It?
Sprint planning is a collaborative effort involving:

  • ScrumMaster – facilitating the meeting
  • Product Owner – clarifying the details of the product backlog items and their acceptance criteria
  • Agile Team – defining the work and effort necessary to fulfill the forecasted completion of product backlog items

Before You Begin
Before getting started we need to ensure

  • The items in the product backlog have been sized by the team and assigned a relative story point value
  • The product backlog is top-ordered to reflect the greatest needs of the Product Owner
  • There is a general understanding of the acceptance criteria for these top-ordered backlog item

Backlogs
The product backlog can address both new functionality and fixes to existing functionality. For the purpose of sprint planning, product backlog items must be small enough to be completed during the sprint and can be verified that they were implemented correctly.

Right Sizing Backlog Items
Product backlog items too large to be completed in a sprint must be split into smaller pieces. The best way to split product backlog items is by value not by process.

Plan Based on Capacity
Mature teams may use a combination of team availability and velocity to forecast what product backlog items can be finished during the sprint.  New teams may not know their velocity or it may not be stable enough to use as a basis for sprint planning.  In those cases, new teams may need to make forecasts based solely on the team’s capacity.

Determining Capacity
The capacity of a team is derived from three simple measures for each team member:

  • Number of ideal hours in the work day
  • Days in the sprint that the person will be available
  • Percentage of time the person will dedicate to this team

The Planning Steps

  1. The Product Owner describes the highest ordered product backlog item(s)
  2. The team determines and prioritizes what is necessary to complete that product backlog item(s)
  3. Team members volunteer to own the work
  4. Work owners estimate the ideal hours they need to finish their work
  5. Planning continues while the team does not exceed determined capacity

Download the free 2-page Sprint Planning Guide and Agendadownload-flashcards

Drawings by Pictofigo