In Part 1 of our series, Introduction to Agile Project Management with Scrum, we began to answer the popular question, “How do we do Project Management in Scrum?” We introduced the concept of the Project Plan and the role of the Agile Project Manager to ‘own’ the Project Plan. In Part 2, we dig deeper into the How-To’s of the Project Plan.
Producing the Project Plan
In order to produce the Project Plan, the Agile Project Manager needs to have some notion of Size, in order to quantify the expected Scope, Velocity, and so on. I’m not going to discuss how one estimates Size, but just assume that there is some size, in Points, that we use. Once we have sizing in Points, the basic formula that ‘makes thing work’ is the following:
Scope (in Points) = Duration (in Sprints) x Capacity (in Points/Sprint),
The size of the work that needs to be done by the team/organization in order to develop, support, and deliver the product. This includes analysis, design, architecture, coding, testing, documentation, bug fixing, release activities, and anything else that is needed.
How long it will take, in Sprints, to complete the Project (release the product, in our simplified Project).
How average amount of the Product the team/organization will produce each Sprint.
I’m going to go one step further, and note that:
Capacity (in Points/Sprint) = BurnRate (in Hours/Sprint) / ProdRate (in Hours/Point),
- BurnRate = the average number of hours the team/organization will spend on developing, supporting, and delivering the product each sprint.
- ProdRate = the average number of hours it takes to produce a Point’s worth of Scope.
The net result is that:
Scope (Points) = Duration (Sprints) x BurnRate (Hours/Sprint) / ProdRate (Hours/Point), or
Duration (Sprints) x BurnRate (Hours/Sprint) = Scope (Points) x ProdRate (Hours/SP),
and both sides of this last equation are each equal to TotalEffort (in Hours), which we typically call Cost.
There are four key variables here, and once we know three of them we can calculate the fourth. This leads to the three main types of Project Planning (for a single-release Project), as seen in the following table.
||When Can I release?
||How Much will it Cost?
||What can we Release?
||We Need Magic…
When doing Project Planning, the APM makes assumptions about the values of these variables, so we typically call these variables the Planning Assumptions:
- Duration = How long it will take, when we know the other variables. This is the result we solve for when we have a known Team (we know its Production Rate), and a known Scope, and want to know ‘When can we Release this stuff?’
- BurnRate = How many hours we expect the Team to spend each Sprint. This is the result we solve for when we have a known Scope, a known Team, and know when we want it. This is the ‘How much will it Cost?’ or fixed price type of Release.
- Scope = The size of the Scope we’ll be able to deliver, given that we have a known Team and a known Cost (we know both Duration and BurnRate). This is what we want to know when we’re doing a ‘What can I release?’ type of Release.
- ProdRate = This is not a variable that can be determined by the APM; this is not really a variable at all in the usual sense. The ProdRate is a function of the Team/Organization’s abilities, the Impediments they will run into, the Constraints they work under (language, tools, etc), and so on. This is empirically derived, and can not be modified at will by Management. Management can influence, or affect, the ProdRate by training people, helping them remove impediments, modifying constraints, and so on… but they can’t really control it. This is why the row with this one as the variables is labeled “We Need Magic…” — because changing the ProdRate to what you want it to be would require magic… just sayin’…
The APM’s job is to work with Stakeholders to determine what kind of Release this is; determine the initial (baseline) values of the four variables, and document the Project Plan that is supported by those numbers. For example, for the Project Plan given in the beginning of this discussion — “We are going to release Features A and B in 3 months (7 2-week Sprints) at a total cost of 2800 Hours,” — the supporting baseline Planning Assumptions might be:
- Scope_baseline = 280 Points, derived as
- Feature A = 100 Points
- Feature B = 60 Points
- Release Activities = 40 Points
- Chores = 80 Points
- Duration_baseline = 7 2-week Sprints
- BurnRate_baseline = 400 Hours/Sprint
- ProdRate_baseline = 10 Hours/Point
Note that key equation here is: Duration_baseline x BurnRate_baseline = Scope_baseline x ProdRate-baseline; which comes in handy when we do our Variance Analysis (which I will describe later) throughout the Project…
Now we have an initial/baseline Project Plan and supporting Planning Assumptions… we may also have an initial Backlog. In fact, we often had to produce some portion of the Backlog in order to determine the size of Scope… so there you are.
Now, how do we manage it throughout the Project? That’s Part 3 of our series.