Here is a link to a story estimates spreadsheet that I’ll use as a reference. If you’d like a soft copy, feel free to email your request to aaronhsmith@gmail.com.
Raw Development Estimates
1-2 senior developers should jointly determine a raw development estimate for each user story, i.e. how many hours do they estimate it would take them to complete all development activities for that user story if they were in a bubble and had 100% focus on this one task for every minute of the work day. They should factor all delivery activities into the estimate, including planning, architecture discussions, technical spike, unit tests, coding, sanity check at deployment, and bug fixes. Enter each raw dev estimate into the spreadsheet.
Adjustment Factors
The raw development estimate must then be adjusted based additional considerations, such as:
- Average Developer – Usually a more senior developer creates initial estimates. Sometimes their estimates reflect how fast they can do it, not how fast an average developer could do it. I actually recommend that they estimate how fast they can do it themselves, but to apply a factor to adjust the estimates to an average developer.
- Requirements Uncertainty – Prior to detailed requirements gathering, user stories have a fair amount of requirements uncertainty. Choose an estimate adjustment that will account for additional work that will be apparent once requirements are better defined. Once you have the Development Ready story, this factor can be greatly reduced.
- Actual Development Time – Whether you assume an 8-hour work day or not, developers have activities that keep them from 100% dedication to development. These include meetings (daily stand up, iteration review, other coordination meetings), helping other team members on their user stories, etc.
Use these individual factors to create one overall Adjustment Factor. Decide on an actual factor % for each, such as 30% for average developer, 30% for requirements uncertainty, and 15% for actual development time. When I multiply the factors (1 x 1.3 x 1.3 x 1.15) and round up, I get a factor of 2. For each project you should define your set of adjustment factors, factor % for each, and overall Adjustment Factor, since every project is unique.
Once you enter your Adjustment Factor into the spreadsheet, it will calculate the Dev Units for you:
(Raw Dev Estimate x Adjustment Factor)/40 hours = Dev Units
Voila! You now have what you need to draft your project timeline.
Posts
Why is this done in units of time rather than story points?
ReplyDeleteThere is no one perfect way for all projects, so if you find story points an effective method for you in your situation, I say stick with it!
ReplyDeleteI do project estimates/bids on a regular basis and need to quickly and accurately estimate a project, including scope, timeline, and budget. After trying a few methods, I found “developer units” (or “dev units”) to be a simple means for calculating timelines and quickly determine resource scenarios. 1 dev unit = 1 average developer work week. For example, when I total feature estimates and know that I have 48 units of work for a project, I can much more easily estimate how long it will take to complete (e.g. 2 developers = 24 weeks, 3 developers = 16 weeks, etc.).
Check out this post for more details on the whole process that I go through: http://www.smartagile.com/2007/10/agile-project-planning.html
Hope this helps!
Aaron,
ReplyDeleteYou've mentioned that raw estimates should include all delivery activities. Where does requirements gathering happen?...Is there a separate iteration for that before you start the delivery iterations.
I suggest you check out this post on the Software Development Lifecycle (SDLC): http://www.smartagile.com/2008/05/agile-software-development-lifecycle.html
ReplyDeleteThis gives you some idea, but it looks like I need to do a write up on the various phases. To answer your question in short, I usually shoot to complete requirements in advance for each 6-8 week milestone of work. Therefore, during the Design phase, we gain an overall understanding of project scope, prioritize the work, create the roadmap, then collect the more detailed requirements for the first 6-8 weeks of work. Once development kicks off for the first milestone, you start gathering requirements for Milestone 2, and so forth. This is a happy medium between waterfall and cowboy coding. You have solid requirements for development, but since you are gathering requirements iteratively you can start development in weeks, not months or years.