There is no such thing as a “best practice”, except perhaps from a marketing point of view. All practices (and strategies) are contextual in nature. In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death. Two of the philosophies behind the Disciplined Agile (DA) tool kit are that choice is good and that you should understand the trade-offs of the options available to you. In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.
Let’s work through an example. A hot button for many people are strategies around cost estimation, typically used for budgeting and forecasting purposes. In DAD initial estimation is addressed by the Plan the Release process goal, the goal diagram for which is shown below. As you can see with the Estimating Strategy factor there are several options available to you. We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range. The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list. Your mileage may vary of course.
The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual. One of the reasons why Choose Your WoW! is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the toolkit. As you can see, there are advantages and disadvantages to both strategies. You can also see that there are situations where each strategy potentially makes sense. Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).
There are several reasons why DAD’s goal-driven approach is important:
For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read.
A few days ago I wrote about ranged burndown charts. Interestingly, if you track the ranges over time you end up with a chart such as the one below which corresponds to the estimating cone of uncertainty (depicted by the dashed lines). It’s interesting to note that this example includes two common occurrences that you’ll see. First, during iterations one and two the gross and net velocities were the same because no new functionality had been identified yet, resulting in an unranged estimate. Second, iteration eight had a very small net velocity because the amount of new functionality was almost as much as the amount implemented, giving a huge estimation range due to the small net velocity.
Previously I discussed the difference between gross velocity and net velocity and now I’d like to show why they’re important. A ranged burndown chart, an extension to normal burndown charts which apply both the gross and net velocity, is shown below. Where a burndown chart uses the (gross) velocity to predict a potential end date, and by extension gives a feel for the potential project cost, a ranged burndown gives a potential range of end dates/costs. Giving a ranged estimate is a known best practice in the IT community.
Because it’s possible that functionality can be dropped from a release part way through a project, perhaps because of a major shift in strategy or in an effort to hit a desired date, the net velocity will exceed the gross velocity that iteration. In this case our advice is the use the change in requirements from the previous iteration to calculate the net velocity.
Note that this blog posting is excerpted from Chapter 10 of the book Disciplined Agile Delivery.
A few years ago, in Dr. Dobb’s Journal I wrote about estimating on agile development projects. In that article I discussed burndown charts and how to extend them to show an estimation range. The basic observation is that there is really two velocities exhibited by a team, the gross velocity and the net velocity. The gross velocity which is the amount of work they complete in an iteration, which is what a regular burndown chart shows. The net velocity is the change in the amount of work still to do, which is the amount of work completed in an iteration less the added amount of functionality that iteration.
So, as the diagram depicts if a team completes 20 points of work in an iteration but 5 extra points of work was added by the stakeholders, the gross velocity is 20 points whereas the net velocity is 15 points. If there’s 230 points on the stack then the gross velocity implies that there are 12 iterations left and the net velocity 16 iterations, providing you with a ranged estimate.
Given that we now have two velocities to chart, not just one, this leads us to evolve burndown charts into what is called ranged burndown charts.