Are there any best practices for estimating Agile projects?
Kim PerrySenior Project Manager| CSX TransportationFl, United States
Within my organization we have shifted to Agile scrum and Agile Kanban. Going into 2021 we are researching best practices for estimating agile development. Because Agile has been in play for many years rather than reinvent the wheel, I would like to understand how others have tackled this issue. Saving Changes...
I'm going to start by stating the obvious - the less you know about the scope of a project, the less accurate your estimate will be; accuracy takes time. This is the same regardless of the methodology or framework you use to run the project. Here are a few thoughts (some obvious, but worth repeating) on agile estimating:
- Size the work appropriately - if it's too big/complex to estimate, break it down
- Estimate by feature. This may sound contrary to the prior item, but it's really about what you communicate. You need to have estimates for tasks to estimate the feature, but features deliver value, not tasks.
- Communicate uncertainty levels, like those in the cone of uncertainty. Don't let rough order of magnitude estimates become commitments.
- Estimating is closely tied to planning. Accurate estimating is dependent upon the accuracy of your planning (planning, not plan).
- Scope changes can affect estimates, regardless of your project management approach.
An important question is, "What doles your company want?" Does the leadership team want to know when the project will finish and how much it will cost before you start, or do they just want to know when the project will start delivering value? Or something in between?
At one extreme, you're doing up front planning and iterative development. You have the product backlog sized and ready before starting work on it. It still feels very predictive. At the other extreme, you might have enough information to plan a sprint, but not enough to estimate a feature release.
Figure out what about estimating is important to your organization. You may have to manage some unrealistic expectations, but this will help you structure your planning/estimating and know which "best practices" will work for your organization. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
I'd echo what Aaron said. If you get too focused on estimating, then you lose many of the benefits of agility.
Your customer needs to understand this. If they want everything estimated up front, then you'll end up with a fixed scope and stringent change management process. This isn't agile. If you're using Scrum and/or Kanban, your customer should be willing to accept some estimation on work that will be done soon, then make decisions before committing to more work later.
As far as techniques, Story Points are very popular and work well if you use them correctly and keep your velocity internal. Don't share your story points with your customer (or even your management). Use them to learn how long it takes to get work done, then you'll be able to tell your customer how long you expect certain features will take. Saving Changes...
The best practice is to avoid the use of the term "best practices", especially when it comes to agile. Remember "We are uncovering better ways...".
I'd suggest reviewing Scott Ambler's blog articles on estimating and planning in this community and also review Mike Cohn's writing on the same topic on his website.
I'd also suggest that slicing work items small and using throughput to forecast completion dates is better than relative sizing using T-shirts, dogs, story points or other fictitious constructs.
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The same you use for estimating any other type of project. Believe me, is my area of research from long time ago. No matter that, is the way I bring the bread to my table. Saving Changes...
Community Champion
