A good key indicator for measuring how well your agile team is performing is the burndown chart. It’s a simple concept—as time passes, the amount of work to do decreases. Of course, there will be days when progress is not as expected or tasks end up larger than originally estimated. A burndown can help your team reset and keep stakeholders in the loop.
Effort estimation is a major challenge for all the stakeholders of a project. Most people generally underestimate situations that may block progress and consider only the best-case scenario for a project. Your choice of estimation method may not be helping, though. Which would be better for your team: estimating by man-hours or by user story points?
Teams should be working toward a target velocity that is based on historical evidence. There may be times when this figure needs to be adjusted, but teams that understand their velocity know that it is a good indicator of what they are capable of achieving in a sustainable way, and this will increase confidence for the teams and stakeholders.
The #NoEstimates movement isn't really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?
If you are agile, you might spend some time estimating. If you’re using Scrum, you estimate what you can do in an iteration so you can meet your “commitment.” But estimation is a problem for many agile projects. The larger the effort, the more difficult it is to estimate. You can’t depend on ideal days. Do your estimates provide value? To whom?
When planning releases, it’s important to understand where team effort is being spent. By using high and low watermarks, a project manager can determine a suitable approach to take when setting expectations and determining whether it is necessary to alter team behavior to focus more on getting those features into a release.
A couple of years ago, the Twitter hashtag #NoEstimates appeared. Its purpose was to start a discussion about alternatives to estimations, but the idea of a project without explicit estimates is odd to most people in software development. However, if you start exploring it, you may find better sources of information to rely on.
One of the primary goals of annual planning is to translate aspirational strategic plans into realistic execution plans. Sadly, rather than delivering plans we can all feel good about and believe in, too often it leaves us depressed about the work ahead of us. This article shares five practical principles to remove the emotions associated with annual planning.
How do you estimate work you've never done before? One proven method is to spike it: Timebox a little work, do some research—just enough to know how long it will take to finish the rest of the work—and then you can estimate the rest of the work. You don’t waste time, you can explore different avenues of how best to complete the task, and your team learns together.
While many teams can use help structuring their conversations, some teams also need some way to know whether the structured conversations that have taken place have provided sufficient information. Kent McDonald explains how using visualization boards can help in these situations.