I ran this 2hr workshop at Lean Agile Scotland in September 2014. These slides are complimented by practical hands-on exercises to help participants learn the basic essentials of planning and tracking a Lean or Agile software delivery.
How long will it take? How much will it cost?
The two questions that constantly haunt development teams. This session is in two parts. Part one is how to estimate before the project has even started - normally in the context of when you're building the business case to secure funding for the project to proceed. Part two then covers the detail of how to size, estimate, plan, and track progress once funding has been secured and the project has started. This is an instructor led hands-on workshop where attendees will work out how much a phantom project will cost and when it will be complete.
2. IANCARROL
L.COM
ABOUT ME:
I’m a Transformation Ninja, not an Agile
Coach or a Project Manager
I run a Code Club every Tuesday afternoon
teaching 9-11yr old kids how to code
Software Development is my life but I don’t
code any more
12. Maximum investment? £ _____.__
1 x PM
4 x Dev
1 x BA
1 x QA
1 x UX
1 x PM
1 x TL
12 x Dev
2 x BA
2 x QA
1 x UX
1 x DBA
2 x Dev
1 x BA/QA
£300/day/person
55 weeks
20 weeks
8 weeks
10 Wks 20 Wks 30 Wks 40 Wks 50 Wks 60 Wks 70 Wks
Window of opportunity
13. HOW MUCH WILL IT
COST?
HOW LONG WILL IT
TAKE?
WHAT IS IT?
18. VELOCITY ESTIMATION
2 WEEKS 8 2 WEEKS 7 2 WEEKS 9 2 WEEKS 8 2 WEEKS
9
2 WEEKS 9 2 WEEKS 7 2 10 WEEKS 2 13 WEEKS 2 WEEKS
9
~9pts per 2 weeks, 116pts total, how long?
SMALL (1) MEDIUM (2) LARGE (4) X-LARGE (8)
19. Maximum investment? £ _____.__
1 x PM
4 x Dev
1 x BA
1 x QA
1 x UX
1 x PM
1 x TL
12 x Dev
2 x BA
2 x QA
1 x UX
1 x DBA
2 x Dev
1 x BA/QA
£300/day/person
55 weeks
20 weeks
8 weeks
10 Wks 20 Wks 30 Wks 40 Wks 50 Wks 60 Wks 70 Wks
Window of opportunity
Post inception view
First – a bit about me!
You will find lots of free stuff on my blog http://iancarroll.com
Community, Community, Community
About this talk
There are many ways to approach estimation & planning
Here’s how I do it
Not all of this might be applicable to your situation
But hopefully you can find some takeaways
I am hoping for some audience participation so please don’t be afraid to take a stab at answering questions that I throw out to you from time to time.
*** AUDIENCE PARTICIPATION ***
Script:
MANAGER: I need a cost estimate on your project.
DEVELOPER: I have no idea I haven’t even gathered the user requirements.
MANAGER: Don’t worry I won’t hold you to the estimate.
DEVELOPER: Yes you will. You will put it in the plan, forget we had this
conversation, and fire me when I go over budget.
MANAGER: Give me a number or I’ll fire you right now.
DEVELOPER: ok, it will cost ten million pounds.
MANAGER: That’s too high.
Don’t be constrained by the typical conversation thread
Explore beyond the boundaries of “How much will it cost”
Objective of the conversation: to understand the ROI
What is benefit?
***ASK THE AUDIENCE*** Who’s working on a project with no apparent biz case?
Basically, your boss is asking you to write their business case for them
***ASK THE AUDIENCE*** what other forms of benefit apart from £££
Reg Compliance, Cost saving, Reputational, Public Sector?
Objective of the conversation: to understand the ROI
What is benefit?
***ASK THE AUDIENCE*** Who’s working on a project with no apparent biz case?
Basically, your boss is asking you to write their business case for them
***ASK THE AUDIENCE*** what other forms of benefit apart from £££
Reg Compliance, Cost saving, Reputational, Public Sector?
Does each option have the right capabilities?
What does the team ramp up profile look like?
Different day rates for different roles?
What is the window of opportunity?
Are you constrained by a deadline?
Objective of the inception is to discover just enough to get going
NOT TO DEFINE EVERYTHING UPFRONT
Out of an inception you should have an initial story list This will most definitely change as you iterate through delivery.
Size, not estimate!
Get the team to separate out the stories into relative sizes.
Cover up the sizing
Get the team to pick randomly from the piles of cards. The objective is to guess for each two week period which stories they think they can complete. Don’t worry about dependencies at this point.
After repeating the exercise many times they will get an average velocity
TIP: Keep the points system within the team. I’ve found it a dangerous currency when it get’s out of the team
I use 1, 2, 4, and 8 as point sizes. Anything bigger than an eight should be broken down.
If you find most of your stories are 4’s or 8’s then break them down further.
Ideally you should have the majority of your stories as mediums.
From this you can produce a linear burn-up chart (see later for guidance on how this should be temporarily used for wet finger in the air planning only!)
Does it still fit?
Burn-up not working out so well – what are your options for fixing velocity? Remove impediments, reduce scope, change the delivery date, add more people?
Watch out for focusing on velocity instead of building the right thing!
Delete the planned velocity once you get empirical data and use forecasts instead
Output vs Outcome tracking
Review the biz case weekly! Fold, pivot, double down
Most deliveries experience the s-curve, or sometimes referred to as the z-curve. Factor this into your planning.
It doesn’t matter what you estimate if you don’t attack variation
Tackling sources of variation is the most important aspect of planning for me.
Demonstrates common sources of variation
***AUDIENCE*** - what other sources of variation exist on a software delivery endeavour?
Why not make the work fit a 5 day timebox?
Then do the 3 day challenge
Predictability!!!
Credit: Kevin Rutherford