Planning Archive

Free Sprint Planning Guide and Agenda

– 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

The Product Owner describes the highest ordered product backlog item(s)
The team determines and prioritizes what is necessary to complete that product backlog item(s)
Team members volunteer to own the work
Work owners estimate the ideal hours they need to finish their work
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: Agile, Assessment, Backlog, Download, Free, Guide, Meeting, Planning, product, sprint

Empirical or Definitive

Derek Huether

– June 29, 2011Posted in: Agile, Project Management

Ever heard of the cone of uncertainty? The cone shows the historical error at certain time periods in a tropical cyclone forecast. What happens today and what has happened in the past is pretty much all we know. We can certainly use all kinds of scientifically proven processes or models to try to predict the future. But, in the end, we won’t know what tomorrow will bring until tomorrow. If you are dealing with machines, you should be able to predict upcoming events with relative certainty. If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none.

We need to assume that baselines may change significantly during a project or in life. In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins. You do everything you can to lay it all out, attempting to account for every possible variable. Unfortunately, you don’t know what tomorrow will bring. So, the further out the schedule goes, the greater the risk something is going to change. What’s it going to be? Is scope going to change or maybe the schedule will slip? With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown. Even some of the unknowns aren’t even known. Just accept it! You’re not the Amazing Kreskin. You can’t predict the future. The only thing that is guaranteed is something is going to change. So, plan for that change. Know the goal you’re trying to reach. Keep your eye on that goal. Now, do what you do. Develop, lead, manage… it doesn’t matter. What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again. Make some adjustments and repeat. You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it. You can not steer a hurricane, only plan for it. You can not prevent change… Can you guess what comes next? That’s right, you plan for it.

SWOT Analysis

Derek Huether

– March 24, 2011Posted in: Project Management

I’m finding myself working through a strategic planning process. I’ve known executives who would just use gut instincts when doing their strategic planning. But when you’re dealing with someone else and their money, don’t be so gutsy. Just do a SWOT analysis. What does SWOT even mean!?

During strategic planning, upper level managers, directors, or executives ask a series of questions. That’s known as a SWOT analysis because they’re trying to identify a organizations’s strengths (S), weaknesses (W), opportunities (O), and threats (T). Because I think a picture is worth a thousand words, please see the Pictofigo enhance grid below.

What are your major strengths? These are internal.
How can you capitalize on them in the future?
What are your major weaknesses? These are also internal.
How can you overcome them?
What are your major opportunities? These are external to your organization.
How can you take full advantage of them?
What are your major threats? These are also external to your organization.
Is there anything you can do about them?

Popularity: 2%

Tags: Planning, Strategic, SWOT

Brooks’ Law

Derek Huether

– March 8, 2011Posted in: Project Management

I was looking for something on the SEI website and came across a piece about Brooks’ Law that caught my attention. Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”. It was coined by Frederick P. Brooks, Jr. in his 1975 book The Mythical Man-Month. You may have already experienced it but never put a name to it.

I would fall under that category. I’ve seen Brooks’ Law happen first hand but didn’t know it had a name.

The vendor was doing predictive versus adaptive planning. They did a very poor job of estimating. Since the customer accepted the estimate, it was just a matter of time that the house of cards would come crashing down. As time progressed through the period of performance, we saw the vendor reach each milestone later and later. (They were following a waterfall approach) At each status meeting the vendor was pressed for an answer to the question of how they were going to recover the schedule. When it was painfully clear that the vendor could not complete the scope of work (within the alloted time), even if they convinced their people to work nights and weekends, they proposed to bring on more people to take care of the backlog of work. That’s right, they were going to bring on a small army with no experience with the customer, the program, or the product. They were going to blow the budget, in the hopes to recover the schedule on the currently agreed upon scope of work.

One stakeholder was very candid when he said, during a status review

It sounds like the plan is to throw as much [something] at the wall as you can and see what sticks.

It’s rather sad that the vendor looked at this as such a simple equation.

Team A (Input) + Team B (Input) = Team A + Team B (Output)

In reality, the equation looked more like this:

Team A (Input) + Team B (Input) = [(Team A * .75) + (Team B * .50)] Output

Have you seen Brooks’ Law on your project? What was the outcome?

Image Source: Dilbert

Popularity: 1%

Tags: Estimating, Planning, Schedule

Parkinson’s Law

Derek Huether

– March 1, 2011Posted in: Agile, Project Management

When I was growing up, I was told the bigger the goldfish bowl, the bigger a goldfish would grow. Keep the bowl small if you want to limit the goldfish size. Thinking back, it’s a pretty good metaphor for my understanding of Parkinson’s Law. The saying “Parkinson’s Law” was first coined by Cyril Northcote Parkinson in his essay published in the Economist way back in 1955.

Work expands so as to fill the time available for its completion

This is what I see happening when developers or others have not decomposed their work to small enough chunks, in order to properly estimate their work. The same goes with meetings if people don’t stick to an agenda.

Yesterday, I saw a (vendor’s) manager trying to break the Parkinson’s Law. Granted, I shook my head at his proposal but I admire the fact that he knows there is a problem and is trying to do something to correct it.

This manager has provided a (non-resource-loaded) schedule that has activities planned to conclude on September 30. The customer is not happy because new work of higher priority has appeared since the vendor provided their 5,000 lined schedule, several months ago. The customer does not have more money it can commit to new scope and they are unwilling to drop scope from the existing timeline. Yes, we all know customers do this. So, what was the vendor’s proposed solution? Going forward, all estimates of work (previously identified and baselined in the schedule) will now have 10% less time to complete. Since they never allocated any slack for activities in their existing schedule, this will become their schedule reserve. Don’t ask me where they got 10%. Tada! Now they have time to complete more work. Oh wait, you mean they shouldn’t use schedule reserve in that way? No, they should not! And they shouldn’t look at management reserve in that way either. I know some out there are going to have a heyday with this. It’s not up to me.

I have to say, the vendor has done a very poor job with their predictive planning. But who is to blame them? It’s not easy! I’ve found adaptive planning to be much more accurate. That 5,000 line schedule was out of date the day it was published. When I first looked at their estimates and later at their schedule, I new the efforts were grossly over-estimated. But, both the estimates and schedule were accepted by the customer. I do think the customer will now get more value for their money.

I got a kick out of the manager’s response when someone in the meeting challenged him on the probability of people being able to complete the work in less time. Though I’m paraprasing, his response was

It’s surprising, if I tell people to have their work finished by Friday COB instead of Monday COB, somehow they just seem to get it done.

That is a clear indicator that people on his team did not do their own estimates and the original estimates were more on the level of a rough order of magnitude (ROM). If it was my team, and I had made the same proposal, I would have had a revolt on my hands. The difference here is my team estimates their own work, within a few weeks of actually doing the work, and we ensure the work is in small enough chunks that the customer can see something of value in a very short period of time.