“An iterative, story-driven process makes it easy to fix a date but difficult to fix what will be included by a given date.”
Predicting a release date is often a big challenge in software development, particularly Waterfall-type development projects. Actually, making the prediction is the easy part - predicting accurately is the challenge.
Assuming a team is in place, determining when a software project will be released is a function of time, features, and quality. Further, by fixing any one of those variables, you can can expect to, perhaps greatly, impact the other two.
As my organization transitions from Waterfall to Agile, we’re challenged with how to accurately perform Agile product release planning and reflect that back to the wider (non-development) organization. With the “old way of doing things” there is a general comfort with holding a written plan, a project schedule, even if everyone knows that plan has a high probability of being wrong.
Waterfall Release Planning
In today’s hyper-competitive business world, a product release date is often defined by company management. This is true in both Agile and Waterfall development environments. In my experience, it’s been true for most, if not all, of the large waterfall development project that I have been a part of the past 25 years.
Once a release date has been set and communicated to the field, the development team heroically tries to meet that date. If you are a lucky engineer, your management team gives you some time to flesh out requirements, create a architecture and design documents, define tasks and a schedule, and ultimately allow your data to influence the release schedule. Even with that luxury, challenges abound to meet this “defined up front” schedule: as you implement more, you learn more, the work remaining becomes more defined, ultimately impacting the project release date - often it is later than originally predicted, rarely is it earlier.
When faced with more work remaining than time allowed, a hard delivery date often forces you to cut features to meet the schedule. The problem is that features may be partially implemented (waste) and often most of the remaining work is quality assurance testing. In those situations, the choice becomes tougher: slip the schedule or reduce testing (and thus quality). It turns into a Kobayashi Maru (“no win”, for those who aren’t Star Trek fans) situation. We’ve all been there, and we all bear the battle scars.
Release planning is different with Scrum
With a Scrum Team producing potentially shippable code with every Sprint iteration, we’ve essentially fixed one of the release planning variables: quality. In order for a product to be potentially shippable, it must have a level of customer-expected quality. This leaves the organization two remaining adjustable dials: time and features.
The amount of completed work (user stories “done”) a Scrum team can deliver in a given iteration is identified as the team’s Velocity. Velocity is a key metric for release planning - it quantifies the capacity of the team for a Sprint. Knowing a team’s velocity, coupled with a sized Product Backlog, the Product Owner can get an approximate idea of what features will be delivered by a specific time. [You can reference numerous books and blogs for further details about story sizing and velocity, with Mike Cohn’s User Stories Applied, and Agile Estimating and Planning being two of the more highly regarded references.]
Time-based Release Planning
If you’re organization is going to mandate a release date, you must readily accept that you won’t initially know the full feature set that will be delivered on that date. But, by using the Scrum Team’s velocity, you can get an approximate idea of the feature set.
Knowing a team’s velocity, how much work a team can get “done” in a Sprint, will help predict how much of product backlog can be implemented by the time the mandated product release date arrives. By using the team’s velocity, the number of sprints that can be completed before the release date can be computed (remember, Sprints are of fixed time). Applying that to the backlog can give you a very good idea of what features will make the release and what are on the “bubble”. Usually this is better than good enough. Features that are on the delivery bubble, those that may or may not make the release, are much lower in priority than those that will be fully “done” prior to the release date. These backlog items shouldn’t be make or break features, and can be saved for a subsequent release.
When the surrounding corporate environment is not Agile and you need to publish a future product feature list to a wider audience, the majority of the the features on the Backlog that comfortably fit into the velocity capacity can be communicated outward, setting expectations and enabling the coordination of public release-type activities such as PR, marketing, etc.
Feature-based Release Planning
If you product must complete a specific set of features before you can release, then using team Velocity can help you predict your release date. By using the team’s velocity, and mapping it to the product backlog, you can predict many sprints it will take to complete the required backlog items. Release burndown charts are great at visualizing how much work is remaining in a release and identifying how many sprints are likely required before you can ship the product.
Because the team velocity can vary from sprint to sprint a firmed up average, team velocity usually isn’t firmed up until the team achieves a regular Sprint cadence - usually 3 or so sprints. To determine a release date early on, you will need to consider velocity variability. Mapping out a release date window can be computed by using the predicted best velocity and predicted worse velocity, which will give you a release window as your target release date. As more sprints are delivered, this release window can be refined.
Product Backlog Considerations
The Product Backlog is a living entity. As you learn more about your customer needs, and hopefully get customer feedback on early sprints, you likely will add and remove items as well as re-prioritize items, all of which can effect your release date. Additionally, the team velocity likely will fluctuate - but with short (2-4 week) sprints, you will have your finger on the pulse, having up-to-date velocity measures as well as average and historical values. Using this data, you can frequently map out how many sprints will be required to deliver true product value to the market.
Continuous Planning
Release planning within Scrum doesn’t happen just once, at the beginning of the release, as it does with waterfall development. The release plan is evaluated and possibly adjusted at the end of every iteration, as more is known and team velocity is refined. Realize that it may not be the project release date that is adjusted, rather it could be the work that will be delivered. As more potentially shippable product increments are delivered by the team, the organization has the opportunity to gather customer feedback, and use that feedback to influence (to add or remove items from) the product backlog. Doing so may change your release date, or the features ultimately delivered. Further, performing this activity regularly, doing frequent customer validation and backlog/release grooming, gives the organization the opportunity to deliver a product that better matches market needs.
For my organization, Scrum has given us a higher level of confidence with our release planning. This year we’re part of a new corporate initiative requires that requires product by the end of 2011. After the recent success of our Scrum pilots, we have a new found confidence in our planning such that we believe we’ll be able to deliver working shippable product by that deadline by using Scrum. We can’t currently say what the complete functionality set will be with absolute certainty, however, but that’s okay. We know we’ll deliver shippable product by the end of the year.
No comments:
Post a Comment