Backlog

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

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

New Scrum Team Challenges

Velocity ChartA while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want? In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you've been doing Scrum for a while. It doesn't talk about things that happen leading up to your team's first Sprint.  It doesn't talk about the complexity of scaling to the enterprise.  It's just vanilla.

I just got back from coaching a new team and I'll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That's where things started to get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we don't know much.

The purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

You're new to Scrum.  You don't have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Again, you're new to Scrum.  How do you know what small enough is?

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Again, you're new to Scrum.  You have no historical data.

Determining Velocity

The velocity of a team is derived by summing the estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.

If you have a new team, not only do you not have a velocity, you won't have any completed work to compare your estimates to and you won't know how many deliverables to commit to.  What do you do?  I think you just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned to do; Act on what you discover.

PMI Eating its Own Dogfood

Current State of the ACP Community GuideI am happy to report that the PMI-ACP Community Guide project is off and running.  Each day, I see new content being added.  I wonder if this is how Jimmy Wales felt in the early days of  Wikipedia.  Our first measure of success is to get the content of each page of The Guide as close to the vision of the ACP Steering Committee as quickly as possible.  Our second measure of success is to reach a tipping point, whereby the community (not the support team) is maintaining the guide.  Remember, future versions of the ACP exam will be based on this Guide.

Community Guide

To reaffirm, there will not be an AgileBOK.  The Community Guide of the PMI-ACP (login required) is an initiative of the PMI Agile Community of Practice to provide ongoing support for the PMI-ACP agile certification.

ACP Support Team

Lead by Joseph Flahiff of Whitewater Projects and myself, the ACP Support Team has kickstarted the Community Guide content creation process.  We are empowered and 100% self-organized.

The Backlog

In order to deliver something of value to the community, Joseph and I leveraged the wiki within PMI's website to create a Product Backlog.  We wanted transparency and for everyone to know what we are focused on.  Every major area of the ACP exam has a page waiting to be edited. If you had a traditional product backlog, the 10 major areas that comprise the Tools & Techniques of the exam could easily be considered Epics.  Each page of our wiki could be compared to a User Story.  We're not estimating our work.  We're just doing it.

Iteration 1

We are currently in Iteration 1, which ends on May 10, 2012.  Of our 15 member team, we asked volunteers to commit to work on the first 7 pages of the first content area.  At the end of each iteration, we can ask members of the ACP steering committee to review what we have done.  It's important that we stay focused, have short feedback loops, and deliver something of value on a regular basis.

Eating the Dogfood

When you think of PMI, you probably think of project plans, schedules, and stuff like that.  As a self-organized and empowered team, we decided what is important, to increase the chances of our success.  Though there should be a predictable date of completion, based on the currently defined deliverables and length of the iterations, we're prepared for things to change.  We may have to rework some of the pages.  We may have some team turnover.  Regardless, we can guarantee we will deliver value on a regular basis.  We can guarantee there is collaboration with the community.

Joining the Team

If you are interested in creating or maintaining articles for the Community Guide, join our team!  If you want to work independently, we welcome your valuable contributions.

 

Simple Cheat Sheet to Sprint Planning Meeting

WHAT IS SPRINT PLANNING?

Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of 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.

WHO DOES IT?

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

HOW DO WE PREPARE?

Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

  • Assign a relative story point value
  • Remove dependencies
  • Create testable examples
  • Define acceptance criteria
  • Meets INVEST criteria

WHAT IS THE BACKLOG?

The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 

ENSURE RIGHT SIZING BACKLOG ITEMS

Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.

CALCULATING A COMMITMENT

To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.

DETERMINING VELOCITY

First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.

DETERMINING CAPACITY

For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?

THE PLANNING STEPS

  1. Remind the team of the big picture or goal
  2. Discuss any new information that may impact the plan
  3. Present the velocity to be used for this release
  4. Confirm team capacity
  5. Confirm any currently known issues and concerns and record as appropriate
  6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
  7. Present proposed product backlog items to consider for the sprint backlog
  8. Determine the needs, sign up for work, and estimate the work owned
  9. Product Owner answers clarifying questions and elaborates acceptance criteria
  10. Confirm any new issues and concerns raised during meeting and record
  11. Confirm any assumptions or dependencies discovered during planning and record
  12. ScrumMaster calls for a group consensus on the plan
  13. Team and Product Owner signal if this is the best plan they can make given what they know right now
  14. Get back to work

// If your team is new to Scrum, download a copy of the Sprint Planning Cheat Sheet //

Drawings by Pictofigo