(For more resources related to this topic, see here.)
People in traditional projects attempt to define and then control scope during the project, while Agile teams approach the problem differently: figure out enough to get started, embrace changes, and then proceed as the way opens. Agile teams, by definition, try to respond to changing market or user needs as soon as those needs are discovered, yet business requires them to plan ahead from time to time. Agile teams know that they cannot predict a project’s outcome, so they use pragmatic planning approaches to tune their development efforts to the latest and greatest needs. This is somewhat like what your local meteorologist does every night on the six o’clock news—his next-day forecast is usually spot on, but the seventh day is always off! Unfortunately, no team (or weatherman) can predict the future, which is why I keep a backup umbrella in my car.
The traditional project metrics of all planned scope , on budget , and by the deadline don’t work for complex technical projects. Here’s a quick example out of thousands: if the project team changes direction because a customer’s needs change halfway through the project, is this a failure? Agile teams would say certainly not, and that it’s actually a success to respond to changing needs, but I’ve actually heard the counterargument that if the team members would have spent more time in requirements gathering, they would have been able to predict all the customer’s needs up front rather than encounter a surprise downstream (as if someone can simply throw out the cast net and drag all the requirements in with the fishes!). This traditional project management logic says that we fail when we don’t achieve the holy trinity of scope, time, and cost. Unfortunately, there are still many organizations, managers, and teams that have this embedded mind-set; this can disrupt the best Agile planning attempts.
I’d give anything to have the ability to see the future of a project, and I’m sure most of you reading this article would as well. Why do you think this is? Humans love to have the perfect plan, and we want the security of knowing what will happen next. We feel safe and secure when we have a tidy Gantt chart, risk logs, and resource plans. It feels good to think about the problem for a long time until we’re sure that we have the perfect solution. We’re problem solvers, after all, so isn’t this what we’re supposed to do? Plans make us feel secure. That is, until they change.
If the real world didn’t exist, my advice to you and your team would be to plan your projects barely enough to deliver value early and spend more of your time adapting to the realities that unfold as a result of delivery. I’d also recommend that you help your teams resist the temptation of estimating tasks to the nth level and to committing to anything more than a week’s worth of work; and please, thwart any attempt by your organization to put you or your colleagues on more than one task or project at a time! Stage a revolt if you must!
Since you live in the real world, and you’re not likely to stage a revolt, I have to give advice that’s a bit more useful than “go ahead, break all the rules.” First, think differently about planning. Consider that, in your current work environment, you are most likely asked to plan projects because the business requires it. Constraints such as budgets, deadlines, and resources (human or not) are finite entities that a ScrumMaster must work with or around in a project. Or are they? Agile gives us the opportunity to pause to think that budgets, deadlines, and people assigned to the project can change based on the adaptations that the organization needs to make in order to win. Be aware that there is a growing trend of modern organizations moving away from the traditional mind-set of projects, and I fully attribute this to the Agile movement. This movement from “crystal-balling” to “continuous adaptation ” is a real, modern business adaptation. Mary Poppendieck, author of Lean Software Development: An Agile Toolkit , says that successful companies don’t create a plan and execute it; rather, they create capacity and respond to reality as it unfolds. Scrum provides two activities for understanding capacity and planning: release planning for long-term and sprint planning for short-term. Both utilize the product backlog as an input. This article will teach you how to use release planning techniques, but in parallel, also think of Scrum as your quiet revolt; use its philosophies and tools to change the way your organization thinks about projects and value(s).
The Scrum framework is the Deming Cycle incarnate: plan-do-check-act. ( Wash. Rinse. Repeat.) The reasons for doing so are as clear as a sunny day: knowledge about requirements, technology, and personal interactions emerge throughout the lifecycle of a project. Owing to this emergence, it makes sense to plan with just enough detail for the timeframe and expected outcome. In other words, long-term plans are coarse in their level of planning and estimation, while near-term plans are very detailed. The following figure illustrates the idea of narrowing the view and focus for the time horizon; roadmaps have wide swaths of possibilities—the roadmap’s range is long-term (years, in some cases). Release plans are usually one to three months (although they can be longer) into the future and the possibilities aren’t so robust; in fact, release plans are just as much about what a team won’t do, as what they will try to do. Finally, you can see that the sprint really nails it down; a team commits to a specific amount of work for a near-term goal.
I used to play violin. Every day before I could practice, I had to tune my instrument. Tuning is physically done by first using the wooden pegs by the scroll, matching the pitch with that of a piano or a tuning fork. I’d get as close to the standard pitch as I could for the A string and then use the fine tuners near th e chin rest to make it perfect. From a perfectly tuned A string, it was easy to tune the other strings because when tuned, the sound waves synchronize and notes would blend into a beautiful synthesis of sound. If you’ve ever watched an orchestra, I’m sure you’ve noticed the string players tuning their instruments several times throughout. This is because the circumstances of the concert change while the concert is in play—the wood of the violin expands from the heat of the player’s body and fingers, strings loosen, and bow hair relaxes through intense pizzicato and crescendo; or perhaps the musician noticed that his instrument was just a bit off while playing the previous piece. Musicians see tuning as part of the concert, part of playing the piece or movement. While getting the instrument back on pitch, the musician is also getting his mind in tune as well.
A release plan is similar to the tuning fork; it represents the direction, goal, or outcomes to which teams should align. Sprint planning is like fine-tuning; turning the little metal fine-tuners at the bottom of the violin bridge in order to get perfect pitch; planning for exactly what we can commit to for one, two, or four weeks of time. I wouldn’t fine-tune my violin today and think that I could play in an orchestra five months from now without re-tuning. I have to re-tune to account for changes in the instrument. So while I dislike the word plan because it has the connotations of finality, exactness, deadlines, and fixedness, I like the concept of tuning product development to the needs of users and customers by use of adaptive planning techniques such as release and sprint planning. And just as tuning is part of playing the piece or movement, think of release planning and sprint planning as part of doing the project.
To make it even more interesting, there are non-standard tuning techniques, called scordatura, evident in French composer Camille Saint-Saens’ Danse Macabre, where the violin’s E string is tuned down to E flat ( http://en.wikipedia.org/wiki/Violin#Tuning ). Likewise, there are different methods and styles of planning releases and sprints. The simple answer is to keep planning simple and efficient; think of planning sessions as times for tuning product development in accordance with the stakeholders’ needs. Since those needs are certain to change, tuning will be a continuous process much like you observe in the string section at the concert. This article focuses on the long-term release plan. It is your responsibility as ScrumMaster to find the best tuning techniques for your team and organization. Carry on, ScrumMaestro.
Start at the beginning – product backlog
A product backlog is an ordered list of features or work to be implemented in a product. It could be infinite in length; that is, there could always be new requirements for a product. The product owner is an actual customer or an internal representation thereof (think of an iPad product owner representing many millions of users), maintains, updates, administers, and ranks the product backlog. Based on market research, a product vision statement, industry analytics, technical innovations, or simply ideas to test, the product backlog represents the product owner’s most valuable ideas and features for a product.
Once the team has selected, planned, and committed product backlog items to a sprint, the product owner cannot make any changes to those items. However, the product owner is given free reign to change the priority, requirements, and even remove any product backlog item that hasn’t been committed and planned in a sprint. This simple game rule drives the product owner into a routine behavior of just-in-time preparedness: the product owner must rank and prepare detail for the most important product backlog items for the next sprint planning meeting. Likewise, the product owner should prioritize and prepare a set of features desired for a release in anticipation of that release’s planning discussion.
Product backlogs are very useful for managing change because work that hasn’t started can easily be re-ordered (tuned) to the market needs at any given point in time. If the team needs to react to an emergency competitor situation, the product owner can defer any not-started items to make way for the features to meet the competitive demand in the very next sprint. Since we know that market needs will change, it’s in the product owner’s best interest to put more planning effort and detail into the most important items the team will need to implement next. In the following figure, the product backlog is depicted as the basis for both long and short-term planning. The product backlog facilitates both levels of planning; that is, product backlog can be quickly and easily re-ordered for long-term forecasting, while in sprint planning, the highest priority backlog items will be planned with utmost detail (tasks, hours, owners, and so forth) because they are ready to be implemented at that time. The leanest implementation of a product backlog is to pull the top item from the backlog, finish it, release to production, followed by the next item, and so on, with no planning other than for one item at a time. This scenario is actually a reality for some companies. However, most teams at most companies engage in both long-term and short-term planning activities and use the product backlog as the main input.
Summary
Release planning is not a crystal ball into which someone can look and predict the outcome of a project. Rather, release planning provides a way for the team and product owner to tune committed work to users’ and customers’ needs without planning for too much detail too soon. The team and product owner must revisit the release plan periodically during the release and work together to deliver features that delight customers.
Resources for Article :
Further resources on this subject:
- How to Focus on Business Results [Article]
- Planning Your CRM Implementation Using CiviCRM [Article]
- IBM Rational Team Concert 2: Agile Development [Article]
