Time & Money, Not Story Points
How much is it going to cost and when is it going to be done? That seems to be the most prevalent question when initiating a project. It's also the recurring theme along the way as commitment to plan (scope, budget, schedule) is the way most businesses think.
Story point estimations and iteration are the norm for many software projects, but there's a dilemma. Stakeholders think in terms of time and money, not story points.
In a services firm, the pressure to meet commitments in the statement of work can be turned up high if expectations are mismatched. Mismatched expectations lead to damaged customer relationships and profit loss.
If you're in a traditional business that has a PMO, there is far more governance with a tight focus on milestones and commitment to plan. If the PMO is not agile oriented, then that requires us to communicate in the language and metrics of the governing body.
Some organizations are aligning to lean/agile ways of working, but most of the time it's not the world we live in. Perhaps in the context of big tech (Facebook, Google, etc.) iterative development, release, and value capture is viable. In other spaces like retail and healthcare, development is done iteratively with a big bang MVP at the end (like a new eCommerce platform or native mobile application). Getting to the "big bang" is where the expectations of budget and timeline are most scrutinized.
So how are we supposed to reconcile lean/agile software development practices against a commitment to budget and timeline? How do we even go about putting together a solid preliminary outline of time and expense?
Rapid Feature Estimation
If you've been leading iterations, then you're likely familiar with applying points to stories in the product backlog using fibonacci sequence (1,2,3,5,8,13,21,40,80,100).
When you're in discovery, you can apply a similar relative estimation technique at the feature level, using a top down approach. Usually it doesn't require a full development team, just a handful of high level experts. It helps if they've worked on similar implementations before.
Baselining Story Points
I've found it useful to baseline 1 story point equal to 1 full day of work across all members of the team. There's a lot of debate on using baselines or equating story points to days, but we can use relative scale from this starting point.
Let's say we have a feature that will require a UX designer, a front end developer, a stack developer, and a QA engineer to deliver.
If an iteration is two weeks in length that's 10 days per team member. Accounting for non-development work and meetings you really only get 8 "story points" per team member per iteration. If we multiple 4 team members by 8 story points, we get 32 as a baseline velocity per iteration.
How Many Iterations?
The feature should have some basic acceptance criteria. I usually like to have these in bullet points as they'll likely become the baseline stories.
After a review of the acceptance criteria, ask the team how many iterations it would take to complete the feature.
Be careful not to let this get too far into the weeds. If the team has experience with the type of work, then this should go relatively fast. There are a few basic assumptions that can be considered:
How customized is the feature vs. out of the box (if developing within a framework or on a platform).
Assume mid-level skills and scale up or down if the team members to be on the project are known.
Are there dependencies outside the development team (individuals, other teams, vendors, systems, etc.)? Be careful not to consider lead times between features within the project, which can be sequenced later. We want to size the feature independently.
Let's say our 4 person team said the feature would take three iterations. 3 iterations multiplied by 32 baseline story points is 96 story points for the feature estimate.
As we continue to estimate features, we can roll up to the project level. In our example, we have 3 features (of course most projects are far bigger):
Feature 1 - 3 iterations/4 people - 96 story points
Feature 2 - 2 iterations/4 people - 64 story points
Feature 3 - 5 iterations/4 people - 160 story points
In the project roll up, we have 10 iterations (20 weeks) with 320 story points.
Features are pretty high level, so they should be relatively easy to sequence.
Take a look at the dependencies between features. What must be done in sequence and what can be done in parallel? Mapping out the features can give us insight into resource needs, when to spin up, and when to wind down the teams.
Team Size & Arrangement
Budget and schedule considerations will influence team size.
Pay attention to potential bottlenecks, but take care not to get too granular. Taking a look at where the heavy lifting lies will help you staff proportionally and scale accordingly.
If the work is stack developer heavy, but UX/UI light, perhaps the team would look like this:
1 UX designer
1 front end developer
2 stack developers
2 QA engineers
Of course there will likely be other overarching roles like architects, DevOps engineers, scrum masters, team leads, etc.
Getting the proportion right will allow you to optimize the resource costs.
Lead times, dependencies, and risks all factor into the how much of a buffer you may need.
Consider things like technical debt, spikes, learning curve, skill level, scope change, and tolerance for overrun.
Putting it All Together
So we may not have accounted for all of our costs like software licenses, hardware, and the like, but our example of rapid estimation does provide us with a starting point for translating story points into schedule and cost.
If we're following sound lean/agile practice, we'll be inspecting, adapting, and integrating continuously.
Iteration 0 for kickoff, 1st sprint planning, and environment setup
12 development iterations (we added 2 iterations as buffer) including user acceptance testing and release activities (done within iteration)
4 member development team cost of $25,000 per iteration.
The project will take 26 weeks and cost $325,000 based on this information.
Of course, in the real world costing and scheduling will be far more complex and variable. Estimates are just what they are: estimates. Managing expectations and communicating along the way is the key.
Estimates at the story level will go up and down. Velocity will fluctuate (but with sound practice will stabilize and increase). Scope will change.
The most important takeaway is that you can estimate a project in a fairly rapid manner and you can translate story points in terms of time and money.