Multi-tasking Mayhem

One of Scrum’s rules pertains to the purpose of each Sprint, which is to deliver increments of potentially shippable functionality that adheres to a working definition of “done.”

Scrum Guide: http://www.scrum.org/scrumguideenglish/

A few weeks ago I was part of a small team creating an Agile training course for our Product Group.  The one-week time-boxed effort was broken into 5 one-day Sprints - we were going to eat our own dogfood and create the course using the Scrum framework.   For our second Sprint, day 2, I volunteered to implement a couple fairly involved stories from our backlog, each requiring me to create a dozen or so slides with associated training notes.  A accomplished multitasker, I dove into the effort, working on both stories concurrently.  Late afternoon I suddenly found myself in the final hour of the Sprint with both stories more than half complete, but neither story Done!  A bit of panic set in as I contemplated my mistake:  if I had worked on the deliverables sequentially, I’d have easily completed at least one Story, come Sprint review time.  As it stood then, I might not have anything done.   I felt momentarily paralyzed by my situation and realized that I’d have to put in extra effort to get the work done in time.  I also realized I had a great topic for my next blog, so all was not lost!

The ability to multitask is often viewed in the workplace as a positive skill:  the ability to juggle and deliver multiple competing priorities in an increasingly complex and dynamic business environment.   However, numerous studies have shown that multitasking only gives the illusion of enhanced productivity, when in actual fact, working on more than one task at the same time often results in less actual productivity!  According to Psychology Today “the mind slows down when it switches back and forth between tasks”.  Each time you switch to a new task you must gain context on the new task while losing some context on the task you left behind.   A Stanford study suggests that when you are switching between multiple tasks, you “couldn't help thinking about the task [you] weren't doing”, leading to a further drop in productivity.

My take-away from this is two-fold:

1. Teams (and individuals) should work on one story/task at a time and deliver on stories sequentially.   The prioritized Product Backlog and Sprint Backlog should is the artifact that focuses the Team.

2. Management should respect the Team commitment (of course!), keep team members 100% dedicated to the Sprint and do whatever necessary to eliminate competing priorities.  When competing work is discovered, the work should be added to the Product Backlog and prioritized by the Product Owner.

Focusing one one story and completing that work before moving on to the next, Scrum teams (as well as individuals) will deliver more work.  Sometimes you have to go “slow” to go fast.

Velocity and Release Planning

“An iterative, story-driven process makes it easy to fix a date but difficult to fix what will be included by a given date.”

-Mike Cohn, User Stories Applied

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.