Backlog Archive

0

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.

 

Popularity: 1%

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

Popularity: 2%

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.

Popularity: 1%

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

Popularity: 1%

Tags: , , ,
8

Project Management Theater

By
Derek Huether
– December 29, 2010Posted in: Project Management

After hearing public outcry over all of the “junk” grabbing going on at Transportation Security Agency (TSA) checkpoints, I heard the resurfacing of the term “Security Theater”.  I’m not certain if TSA “gets it”.  If you are going to take true action to help fix issues, you need to treat the cause and not a symptom.  Have a shoe bomber?  Make everyone take off their shoes.  Have someone wearing baggy clothes wear a bomb onto a plane, spend millions of dollars to see beyond the baggy clothes.  Without telling you what I did, I bypassed both the new full-body scanners and the TSA pat down in two major airports within the last few weeks.  Certainly, I didn’t want to deal with either so I was happy.  The problem I have, as a stakeholder, is a lot of money has been spent and the issue still exists.

Imagine if that happened on your project?

I see Lessons Learned meetings or a Retrospectives as opportunities to help you refine your processes.  You see what works and doesn’t work.  You find out the root causes and then you make changes.  You refine.

Today I witnessed what I call Project Management Theater.  The vendor loves to use Gantt charts.    On a program level, both the customer and vendor follow a more traditional waterfall process.  At last count (5 minutes ago) the “integrated” schedule had 5,954 lines.  (Internally, I use a backlog and Kanban) Within seconds of reviewing this monster schedule, I could point out improper work decomposition, improper work package mapping, description inconsistencies, improper use of preprocessors or successors and the list goes on.  If your customer prefers the use of Gantt charts over Burndown charts, I’m not going to argue with them.  Whatever the culture will demand, you have to work with it.  But, the problem here is these are just charts.  They are only as good as the data driving them.  When the customer asked me today what I thought of the split view the vendor provided (WBS/Gantt chart), I was blunt.  I hate it. I added, everything that needed to be reviewed at the meeting could have been presented either as a milestone report or backlog.  Instead, we spent most of our time trying to locate activities and get statuses on each.  On top of that, the schedule provided had not been updated in two weeks.  Therefore, we had to ask over and over again if certain activities had been completed.

If you’re going to commit time and money for a support activity, please make sure the resulting “thing” has some value.  At the next meeting, I expect the Gantt chart to go the way of the dinosaur.  I’m advising the customer to request a milestone report from the vendor (instead of the WBS/Gantt Chart).  In the end, I want to ensure the vendor is reaching agreed upon milestones.  Currently, the customer is so distracted by all of the inaccurate details of the schedule, they forget to ask the hard questions about the milestones.

Eliminating the Gantt chart is not going to solve the problem.  Next week, I’m going to show the executive team a Kanban of the milestones.  Let’s see if they find more value in that.

Like the image? Find it at Pictofigo

Popularity: 1%

Tags: , , , ,
Older Entries