Traditional projects often say scope is fixed, and the variables are how long it takes to deliver the scope, and how much the scope will cost.
I have watched numerous presentations contrasting agile to traditional software development. The story goes like this. A traditional project is usually scope constrained. Similar to a fixed bid scenario, we are told what the scope of the project must be, and then we will research the request, estimate the time and cost, and come back with a proposal that includes our price and the date we can deliver on.
Agile projects are stated as being the opposite. Instead of being scope constrained, we say that agile projects are time and resource constrained. In the agile example, we say the customer wants as much functionality (scope) as they can get by a fixed deadline, and we can only use the resources, or team members, that we currently have. The customer is asked to prioritize their needs, and then the agile team will estimate how many of the needs they can deliver by the due date.
Agile projects often say Time and Resources are fixed, and the only variable is how much scope can be delivered by the fixed date with the fixed team.
When I listen in on these presentations I will often see an attendee jot down a note “use traditional for fixed scope, use agile for fixed date projects……..”
But is this true? No it is not. Agile works well for fixed scope too. As a matter of fact, I prefer agile to traditional for fixed scope bidding. So how would you apply agile to a fixed scope request? Almost identical to the way we plan for a date driven project.
How the Traditional Fixed Scope Bidding Process Works
Let’s start by looking at the traditional process for bidding on a fixed scope project. A potential client could ask us for an online auction system that supports mobile devices and allows for 500 concurrent users. The major features that must be there are auction creation, item bidding, seller feedback, online help, and the ability to search for auctions.
We could meet with our project team and discuss the scope. The team would break down the feature requests, outline the dependencies and critical path, then estimate the major tasks. In this example the team comes back and says it is a 12 week project, and 7 team members will be needed.
Our burden rate per team member is $3000 per week, so we determine that our cost to do this project is: $3000 X 12 weeks X 7 team members = $252,000.
We would like to make some profit on this project so we add in another $48,000 for our profit, and we tell the customer, you can have the scope you requested, in 12 weeks, for $300,000. We have now completed our fixed bid process for this project request. This is the traditional fixed bid process.
How the Agile Fixed Scope Bidding Process Works
So how could we use the agile process to bid on a fixed scope project? In summary, we estimate how many iterations will be needed for the scope requested, and what our expense is per iteration. Let’s look at this in detail.
First, the team obtains the requirements from the customer. The team will review the requirements and if possible ask the client refining questions about the needs, often improving and refining the definition of scope.
When we are done refining our understanding of scope, the agile team discusses the requirements and converts them into user stories, if they are not in this format already. Once we have the list of needs/stories, the team discusses each story requested, and the new stories are compared to similar ones the team has delivered in the past. The table below illustrates how this comparison is done.
Comparing new story requests to previous stories delivered is an effective and efficient way to estimate project requests.
In the first example, the new story request, auction bidding, is determined to be about the same size and complexity as create a quote. Create a quote was delivered by this project team a few months ago and it was sized at 8 story points. So the team estimates auction bidding will also take 8 story points
Teams usually gauge what they deliver in story points per iteration. So for our example, we will say this team has averaged 20 story points delivered every 2 weeks (a 2 week iteration) on previous projects they have delivered.
In our example, the team totals up the all of the story estimates and it comes to 60 story points for the scope requested. Assuming 2 week iterations, and the fact that the team averages 20 story points per iteration, the team estimates needing 3 iterations (6 weeks) to deliver the project.
However, an alert Scrum Master notes that the team averages 20 story points per iteration, but they have delivered as few as 15 story points on some of their slower iterations. The Scrum Master suggests that the team commit to the worst case scenario instead of the average. The team agrees and uses 15 points per iteration as their estimated throughput (aka velocity) and they tell the customer they can deliver the request in 4 sprint, or 8 weeks.
A team estimates the story points for each story, then looks at their past work to see how many story points they usually deliver in an iteration. The result is a project plan (which agile teams often call a “release plan”).
Once an agile team estimates the number of iterations needed and the corresponding delivery date, we still need to estimate how much it will cost before we price the work. We do this by understanding what the burden rate is for the individuals on the team (just like traditional), and then totaling that up for 8 weeks of work.
In our example, each team member has a burden rate of $3000 per week, and we have 7 members on the team, and we will need them for a total of 8 weeks (4 iterations), then our cost for the project will be: $3000 X 7 team members X 8 weeks = $168,000.
To make some profit once again we add in $48,000 and we tell the customer we will deliver the scope they requested in 8 weeks for $216,000.
All of the estimates above assume all team members are 100% allocated to this project.
Summary
This case study makes many assumptions, but hopefully it makes my point clear. Agile is not limited to time constrained projects. Agile can be used for any project constraint – scope, resources, schedule, or other.
As mentioned, I prefer using Agile for fixed bid work because I usually find the estimates as good or better than traditional estimation methods. I also find that the team can usually estimate the work much sooner since they do not break each request into tasks, and estimate at the task level.
Trying to estimate a project request right now? Drop me an email and I will help you apply this process or answer any questions you have.