Backlog Archive

2

New Scrum Team Challenges

By
Derek Huether
– December 8, 2012Posted in: Agile, Project Management

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.

Tags: , , , , , ,
1

PMI Eating its Own Dogfood

By
Derek Huether
– May 4, 2012Posted in: Agile, Project Management

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.

 

Tags: , , , , ,
0

Free Sprint Planning Guide and Agenda

By
Derek Huether
– July 22, 2011Posted in: Agile, Project Management

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 Agenda

Drawings by Pictofigo

Tags: , , , , , , , , ,
0

Zero Cost Effect

By
Derek Huether
– April 13, 2011Posted in: Agile, Project Management

I had dinner with a colleague the other night.  I inadvertently quoted something verbatim from Dan Pink’s book, Drive. My colleague said if I liked Dan Pink’s work, I should read something from Dan Ariely.  So, I started on Predictably Irrational:  The Hidden Forces That Shape Our Decisions. Wow, this book is crazy!  I’m not going to go into any more details in the post other than a comparison of an experiment detailed in the book and something I’ve seen in the real world.

In the book, the author described an experiment on 34 Halloween trick-or-treaters. As soon as the children knocked on the door, they received 3 Hershey’s (each weighing about 0.16 oz.) and were asked to hold the Hershey’s they had just received in their open hand in front of them. Each child was then offered a choice between a small (1 oz.) and a large (2 oz.) Snickers bar, under a Cost Condition and under a Free Condition.  In the Free Condition, they could simply get the small 1 oz. Snickers bar (for free) without giving up anything or they could exchange 1 of their 3 Hershey’s for the 1 large Snickers bar.  In the Cost Condition, the children could exchange 1 of their .16 oz. Hershey’s for the small (1 oz.) Snickers bar or exchange 2 Hersheys for the large (2 oz.) Snickers bar.  They could also choose to do nothing but all of the kids chose to make an exchange.

Experiment Results

In the Free Condition, in which the small Snickers bar is free, demand for it increases substantially (relative to the Cost Condition).  The results demonstrate the attractiveness of zero cost.  People gravitate more toward options that do not require giving up anything.

Example of this on a project

At work, I’ve had a Product Owner (PO) who wanted to add items from the Backlog to the Sprint.  During sprint planning, the team basically added a buffer, to account for unforeseen events.  I know people are going to crucify me for this, but basically, the Product Owner always seemed to want to shift priorities of work mid-Sprint.  Rather than killing the Sprint, we added a buffer.  This would allow new work to be entertained without totally derailing the work already being completed.  Yes, we could have used Kanban and all of this could have been avoided.  But, Kanban wasn’t an option.

So, what happened?  I offered the PO a deal.  I could allow him to add a certain amount of work to the Sprint for free. When I did this, he usually asked for smaller deliverables (relative to other items on the backlog that were ready to work).  But, when I said some work would have to come off the table to pay for the new work, he always went big.  He would choose larger deliverables relative to other items on the backlog that were ready to work.

All I can say is we truly are predictably irrational.

Yes, the links to the books are affiliate links.

Tags: , , , ,
7

Valentine’s Day Pull System

By
Derek Huether
– February 14, 2011Posted in: Agile, Project Management
Nothing is quite as romantic as sitting with your husband or wife, sharing a dinner of fondue.  Nothing, that is, unless you’re sitting with me.  I’m not a big fondue guy.  This is sad because my wife loves it.  She enjoys the whole process.  To counter that, I like my food to be given to me, already prepared.  I enjoy the results!

So, leave it to me to point at the fondue pot half way through dinner and yell “Fondue is a pull system!  Fondue is a pull system!”

What is a pull system you ask?  Perhaps you’ve heard of Drum-Buffer-Rope or Kanban?

Businessdictionary.com defines it as a Manufacturing system in which production is based on actual demand, and where information flows from market to management in a direction opposite to that in traditional (push) systems.

The idea behind a pull system is to keep a smooth production flow.  For the sake of argument, let’s say N is a volume of work output.  It can be trouble-ticket call volume, software development, or hardware manufacturing.  Any of these work in the example.  If you and your team can consistently deliver quality N in a month, and keep a good work-life balance, you should know that a C-Level executive asking you to deliver N+10 is going to create bottlenecks in your process flow.  Your overall delivery velocity is going to slow and your team is going to work longer hours trying to deliver N+10.  This increase is unsustainable unless something changes.  You need to get back to N, either by cutting back the work, expanding the amount of people or things to complete the work, or find some efficiencies.

You limited your work in progress (WIP) for a reason!  If more is going into your process than is coming out, you’re going to accumulate a backlog.  For every unit exiting your process, you should have another unit ready to enter it.

For fondue, you limit your work in progress by the amount of long-stemmed forks you have to put into the pot (caquelon).  Before you start, you cut up all of your fruits, vegetables, meats…whatever you plan to dip.  That’s your product backlog.  You then begin dipping whatever you have, X at a time.  We had 3 forks each.  When the food is done, you take it off the fork, add another piece of food, and back into the pot it goes.  You can’t eat anything until it’s done with the process.

Am I a romantic buzz kill or what!?

Image: Recipe Tips

Tags: , , ,
Older Entries