Strategic CIO // IT Strategy
Commentary
8/5/2014
11:35 AM
 Dan Radigan
Dan Radigan
Commentary
100%
0%

Dev Project Estimates: Stop Blowing It

You can build a culture of accurate development project estimation. Follow this advice to get your software development roadmap on the right track.

Effective estimation is one of the toughest challenges software engineers face in their jobs. Regardless of team size, it's important to crisply define, estimate, and distribute work throughout a team. As teams get larger, it becomes even more important to build good habits around planning and estimating work. Lack of planning and estimating reduce confidence in a program, break down relationships between the team and the business, and make development harder on everyone. In this article, I offer techniques to make estimating easier and show how to build trust across teams in those estimates.

Let's start with defining a unit of work. Agile teams use terms like epic and user story, traditional teams may use task or feature, and all software teams use the term bug! I'm going to define work as a change from the current state that requires effort from one or more people to deliver. Properly defined work also includes clear metrics for success, so the team knows when work is complete.

Start with a product roadmap
Every team needs to build a roadmap. It's critically important to the development team to understand how the code base will evolve over time. The roadmap will likely have four to six major initiatives. Each initiative will have several large features inside of it. Each feature will likely have multiple components. And each component will require a set of tasks and user stories needed for delivery.

It's important to break down each component into a series of 8- to 16-hour tasks. The most effective estimation sessions involve the entire team. As a team plans, questions about how individual streams of work fit together will arise. This is a good thing. These questions foster organic conversations about the project and minimize surprises. If a team is new to estimating together, start with at least the product owner, Scrum Master, and the development team (dev and test engineers).

You're probably thinking, "I can't do that level of detailed estimation for my entire roadmap!" You're absolutely right. You shouldn't. Focus on doing detailed estimation for only the first few items in the feature pipeline. Once the team understands the effort required to deliver the first few items, it can more broadly forecast the scope of work for items deeper in the backlog. This highlights a key rule of thumb: Accuracy of estimates declines as the scope of work gets larger.

Read the rest of this story on Dr. Dobb's.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
zerox203
50%
50%
zerox203,
User Rank: Ninja
8/6/2014 | 11:55:35 AM
Re: Dev Project Estimates
Thanks, I checked out the full article over on Dr. Dobb's, that was very in-depth! Of course, it has every right to be so - Project Estimates are something we've all struggled with since the dawn of time,  and the modern software development landscape does not make things any easier! To that end, I like your approach here - not that this methodology is a one-shot bandaid that will fix your problems (because there isn't one), but that, over time, it will lead to a generally better software development environment, and a better way of understanding your own estimates internally. After all, isn't that what's most important? an estimate can only be 'accurate' if everyone on the team agrees on it and what it means.

The other benefit of this methodology is that stretches and scales regardless of the product at hand. You can move to a completely different kind of project, and while it will require plenty of adjustments (IE the relative scale of this 'work story' items), this basic template will still function. On the other hand, the whole thing hinges on your team members being on board, and you can't always wring blood from a stone. If they don't like the model, or if they don't compensate for the 'cost of doing business', etc.,  you won't get accurate estimates, whether it's time or some other measurement. There's really no way around that.
Thomas Claburn
100%
0%
Thomas Claburn,
User Rank: Author
8/5/2014 | 4:53:59 PM
It's always a moving target
Because programming is both a scienec and an art, it's difficult to scope a project accurately. There are often may ways to do things and each road has its own timing. And things change as systems get implemented. If your estimates turn out to be close to your results, you've done well.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Dec. 9, 2014
Apps will make or break the tablet as a work device, but don't shortchange critical factors related to hardware, security, peripherals, and integration.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of December 7, 2014. Be here for the show and for the incredible Friday Afternoon Conversation that runs beside the program!
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.