Session Title: Planning a Long Project

11:15-12:30 Wednesday Nov 15

Moderated by Kelly Weyrauch (kelly.weyrauch@medtronic.com)

We defined “long” as a year or more.

Scope? Is it well understood and stable (at some level), or emerging / volatile?

- Planning must account for volatility in requirements, wherever it is.

- Must acknowledge that requirements will emerge, and planning must align the team’s practices with the team’s expectations for emergence. (A project should not mislead itself with a mistaken assumption that requirements are well-understood and unchanging, and instead should establish a reasonable expectation for how requirements will emerge (how much and when), and establish practices that align with that expectation.)

The longer the project, the greater the need for more regular assessments of the project’s value. (Don’t want to let a project go for 18 months only to realize it is now worthless.)

- Better yet, break a large project up into smaller ones.

- Must establish gates that include a go / no-go decision possibility, or allow for the possibility of a significant re-direction in scope, time, cost, ….

Long projects should always be clear on “What is left?”.

The planning for a long project must establish how the project will handle changes in infrastructure (e.g. new operating systems, new technology, etc.) that are more likely to occur in the middle of a large project than a small project.

The resource plan must assume that people will change over the life of the project – it cannot depend on the same people being available for the entire duration.

We discussed two ways to handle uncertainty in the definition of the product backlog. (This seemed to apply to any size project.)

1 – Add backlog items for the uncertainty, along with a Point estimate that reflects the reasonable amount of effort to allocate to the resolution of the uncertainty. An item called “Undiscovered _____” is a good way to identify risks that can be identified and planned, even if not clearly defined. A specific example is “Undiscovered tooling issues” to deal with problem with the development platform that could reasonably be assumed to happen. Another example is “Undiscovered architecture issues” to allow for problems with the underlying architecture that are likely to be found as impediments to team progress. Not to be confused with “padding”, these are items that we can defend as legitimate elements to be accounted for in a robust plan.

2 – Plan for Points to change over the life of the project, either going up if the plan assumes scope will grow, or going down if the plan assumes scope will be reduced. (Don’t let ourselves always assume growth.)

Both options produce the same impact to the date projection in a Burndown, but convey different messages. The first articulates specific things when those things can be explained, making them visible so the team (customer and developers) can make decisions on how to manage the uncertainty. The second allows a plan to account for things that can’t be defined up-front, but are “known” to be reasonable based on past experience. (“Every project like this has had an average of 25% scope increase, so let’s build that into our plan. You say that doesn’t give an acceptable projection for an end date? OK, what are we going to do on this project to limit scope increase to only 10% so that we could hit the end date.”)

We talked about different ways to build a burndown for a long project, and adjust it over time. (The moderator was quite clue-less for at least 10 minutes of this discussion. =:^) One is to use a points-burndown and associated velocity profile to show what we think our date-projection will be, making adjustments if we aren’t hitting the target we want. Another is to use a list of functionality, drawing a line at what we think will be done by the date we want.

We ended with lots of discussion on burndown/velocity graphs, but the moderator was so involved in the discussion that he didn't take any notes. Any other attendees have something to add here?

 Create your own business wiki!HelpPublic, not yet premium Privacy Policy RSS