Estimating and planning Agile projects
-
Upload
murray-robinson -
Category
Technology
-
view
1.769 -
download
0
description
Transcript of Estimating and planning Agile projects
Estimating and planning agile projects
Presented by:
Murray Robinson
[email protected], [email protected], Twitter: @MurrayR3128, Blog: Agileinsights.wordpress.com
Estimating is hard to get right
“On average Victorian Government ICT projects will have more than doubled in cost by the time they are finished” Victorian Ombudsman Report into ICT Projects
Myki $1.5B vs $1B estimated
Suez Canal 3X more than estimated Sydney Opera House 15X more than estimated
Why is estimating hard to get right?
Overly optimistic predictions of scope and budget to get a project approved and funded
Faulty forecasting techniques Inadequate information Scope creep Everything looks easy at a high level
The Cycling Analogy
The Cycling Analogy
Why do we need to estimate
Stakeholders need estimates of how long things will take and cost:
To decide if they are worth doing, To compare alternative investments and
solutions; To allocate resources and To plan product launches.
Agile estimating and planning
Review Progress &
Identify Velocity
Analyze stakeholder
requirements
Identify and rank features
or stories
Estimate each feature or
story vs known stories
Develop an iteration and release plan
Determine the teams velocity
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 190
20
40
60
80
100
120
Team Velocity
Estimated velocity Actual velocity Power (Actual velocity)
Identify features and stories
Move emails
Search by keyword
Open RTF email
Send RTF email
Create and send basic email
Delete email
Open & read basic email
Create sub folders
Send HTML email
Create HTML email
Import & process contacts
Feature
High level story
Low level story
Define stories or features
Acceptance CriteriaGiven that I am {this actor}And {the situation is X}When I {do this step}Then {Y happens}
Business Rule:When A and B then C
Interface Design:UI Wireframe for X
The Estimation Game
Planning Poker
Agile Release Plan
1 2
3
5
1 23
8
12
340
1
2
3
5
8
3
235
5
40
40
1
2 2
3 5
3
2
3
2
2 2 1
3
5
3
5
3
3
32
2
3
5
3 5
User Business Process
1 feature pt = approx 6 story pts
Agile estimation using velocity
What if you don’t know the teams velocity?
When velocity is unknown use a combination of traditional and agile estimating approaches
Determine features and estimate stories in points as before
Team provides an optimistic and pessimistic estimate of the features and stories they can commit to in an iteration. Use the pessimistic estimate as the velocity
As a check do a bottom up estimate of days effort taking into account that developer effort is only half the team effort and rework and defect fixing is often as much as the original effort again
Traditionalestimation
Start Project Timeline
Estimating from ideal team structure
Online Application
DEV50%
QA17%
UX11%
PM10%
BA12%
DEV56%
QA19%
PM11%
BA14%
Back end Application
The effect of rework
Rework10%
Initial work90%
Rework25%
Initial work75%
Rework50%
Initial work50%
Outstanding team90% test case pass rate
Average team70% test case pass rate
Poor quality team40% test case pass rate
Rework = Defect fixes = Failed tests
Proposals and SOW’s
Software development projects are always new
We uncover the real requirements and solutions by doing
Big up front designs lead to over specification of the wrong things
Fixed price & scope waterfall projects become variable price, scope and time on the first change request
Agile can guarantee delivery on time and on budget of the features that are most important to the customer
Move to Agile fixed price, fixed team projects with a target variable scope
Waterfall vs Agile
Future topics
Initiating an Agile project Agile Kanban vs Agile Scrum Scaling Agile for Large Teams Reduce wasted time and effort in software
development Project retrospectives The business case for Agile
Feedback