Project Estimation slides from Barcamp Memphis November 13, 2010. A short presentation of strategies for estimating the level of work it takes to complete software projects
Call Girls Hebbal Just Call 👗 7737669865 👗 Top Class Call Girl Service Bangalore
Project estimation: When the design is bigger than the back of a napkin
1. Project Estimation
When the design outgrows the back
of the napkin
Johnnie Fox
www.britesparkz.com
@johnniefox
2. Estimating Sucks
Reasons why people don't want to Estimate
• Coders hate doing it
• Assumption that it won't be correct anyhow
Benefits of Estimating:
• Builds Reputations
• Sets Expectations
• Skipping this step is the yellow brick road to Hell
• Directly affects customer satisfaction
• Good estimates make team members feel productive
• There is no pot of gold at the end of the rainbow unless you
put it there
• Keeps you from taking bad projects
• Leads to good project management
4. 1. Understand the problem
What is:
o This project anyway
o Technologies involved
o Clients side involvement
Hardware
Hosting
People
Departments/managers
Importance of Customer involvement
o Who are the key contacts? Could be one or multiple
o Need Only ONE Decision Maker!
o You know they are participating when they tell you you
have it wrong
5. 2. Mock ups / Wireframes
Should be Low-Fi to begin with
bigger than a napkin - get more
napkins
Tools
• Photoshop
• Google docs/drawing
• Napkins
• I like Balsamic Mock-ups
• Tons of others - just search
Examples :
www.wireframeshowcase.com
photo credit:
http://www.wireframeshowcase.com/wireframes/detail/medstars/
11. 6. Make a list of tasks
Modified Delphi Estimation method.
Developed by the Rand Corporation in
the 40's
Fancy word for list:
• Work Breakdown Structure (WBS)
Key Points:
• Members of the team meake their list of tasks SEPARATELY
• Everyone must participate.
• After lists are made members meet and compare lists.
• If there is no conflict and you didn't get any additions, then you
are doing it wrong.
12. Time estimates are like hockey:
It isn't really a game until a fight breaks out
• Estimate separately
• Fight out the differences together
Photo Credit:Peter
http://www.flickr.com/photos/psmithy/3282607845/
15. About those lists
How do you create a task breakdown for something you
haven't done before?
• You can't
1. Do a prototype
2. Find someone who has done it before sub-contract/buy
training
Common pitfalls:
1.Undiscovered requirements
• Undiscovered requirements
• Undiscovered requirements
• Overoptimistic/pessimistic team members
• Undiscovered requirements
• "You don't know how much you do not know"
• Uncommitted members of team (includes customer)
16. If I add up all the time
....its too much
• Since the customer is involved.
o Let them decide what to cut. Or to add budget.
• Add up all the time, then decide if you want to buy/discount
the project
• Check your assumptions
o maybe you can re-factor the solution
o some features may have to be cut
• Reality will not change no matter how convenient that
might be or how much you need it to
• Some projects should be avoided.
Photo Credit: Anthony Kelly
http://www.flickr.com/photos/62337512@N00/433
5060317/
17. Putting it all together
1. Understand the problem
2. Make a Wireframe.
3. Make the Customer tell you why its wrong
4. Repeat steps 2 and 3 until you don't get it wrong.
5. Make a list of tasks (Work Breakdown Structure)
6. Estimate time in fixed amounts
7. Use the skill of the people you work with.
8. Make a list of declined, deferred and discussed items that
are NOT included. Put this list in the contract
9. Contract should state that only features that are in the
contract are included. No others.
18. Further Reading
Extreme Programming by Kent Beck
Getting Real by 37 Signals
Applied Software Project Management by Stellmane and Greene
Rapid Development by Steve Mconnell
19. About me:
Johnnie Fox
Twitter: @johnniefox
www.britesparkz.com
www.johnniefox.com
Cat Herder
Fire Fighter
Bad Dancer
Project Manager
Researcher
Programmer