TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Resources  >  Books Guide  >  Detail: Agile Estimating and Planning

Books Guide

ThoughtWorks



Quick Book Search
Advanced Book Search


Book:
Agile Estimating and Planning
Author: Mike Cohn
Pages: 320Published: 2005
Publisher: Prentice HallISBN: 0131479415

Rating StarRating StarRating StarRating Star

Email This ContentPrint This Content
Buy Book Click to Buy

Topics:  Agile Methods / Project Planning / Requirements Gathering / Process Improvement / Project & Team Management / Requirements

Description:
This book goes beyond the strategy of just enough planning and estimating, and shows readers how to make Agile practices truly work organizationally. Save time, conserve organizational resources, and manage software projects more efficiently by learning to anticipate future needs. Key points are supported by case studies derived from real-world projects. Cohn teaches the nuts and bolts of estimating a project, an iteration, or even a task -- and teaches a variety of approaches to effective estimating.

Keywords: Software Engineering / Agile Development

 
Member Reviews
 Review by Mark Cole   Mark.Cole@gmail.com
Back to Top

In "Agile Estimating and Planning," Mike Cohn presents a strong case for using agile and iterative processes, such as Scrum, to design software projects. This book deals with the issue of managing uncertainty, which (as stated in the book’s forward) is "plan, plan, plan, do." Agile methodology argues for "plan-do-adapt, plan-do-adapt."

In the book, Cohn discusses the planning stage rather than the creation of a plan. A "static plan" will change, and spreading out a plan throughout the project can be truly agile and useful. Cohn also covers "Agile Estimating" that involves writing stories on cards and estimating how long each story will take. One interesting idea is planning poker. In planning poker, every member of the agile team plays a card with a number representing how long they believe the task will take to complete. The people with the lowest and highest estimate must explain their bids, and then you play the round again.

Later in the book, Cohn reveals he favors short schedules with two-week iterations. He also explains tracking and communicating, his thoughts on why agile planning works, and closes his book with a case study using examples from the book.

Cohn gives an excellent project management perspective on agile estimating and planning. He communicates great ideas and explanations about agile methodologies. I enjoyed the case study because it gives an accurate feel for working on an agile team. However, it does not cover enough of the problems of managing a software product. I would like to have read the opinions of team members concerning the short iterations and the overhead from continual planning and demonstrating results.

I was disappointed that Cohn did not include more details about each iteration; only the first iteration is covered in depth. I would have liked to see more iterations spelled out so that readers learn not only how to master agile development, but also how to plan and estimate the end game--showing how things can go wrong, team members change, and conflicts arise among team players.

Overall, this is an excellent book that contains great project management ideas on quantifying uncertainty by estimating and planning a software project.

"Agile Estimating and Planning," gives practical advice on how to estimate and plan agile projects. It shows how agile projects work, and gives real-world examples and case studies on managing software development uncertainties.


 

Member Comments
Add Your Comment
 
Comment:    
by George Stark 8/13/2008

This book is highly overrated and does not address many of the issues with estimating in an Agile environment. It assumes a very stable team (which is rare after a couple of iterations), it uses story points which is only useful as an "in the moment" approach to sizing and does not allow for historical or cross-project learning, and it fails to take into account any level of quality or rework in the project. Planing poker is not a robust technique and cannot be scaled for any decent sized organization. Overall, this approach to estimating should be ignored.

 
Back to Top


 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Infosys

Rally Software


Agile Development Practices 

STARWEST