So today, I’m asking you to take a moment to fill in a one-question survey for me. It’ll help me ensure I'm discussing the topics you are most interested in. The feedback you provide in this survey will be added to our list of topics to address in our blog and newsletter .

Please take a moment to fill in the survey here.

Thank you.

Here's the session description:

Agile Planning & Project Management

In this session we will shatter the myth that agile teams can't plan. We'll start by looking at the benefits of the short cycles of iterative and incremental development. We'll then look at the six different levels of planning that occur in agile organizations. We'll see what user stories are and why they've become the preferred approach to planning and managing the work of an agile team. We'll look at how user stories are estimated with the popular Planning Poker technique. To do that we'll discuss the merits of relative estimating and abstract approaches such as story points and what a point really means. With an initial plan created, we'll look at how agile teams use the concept of velocity to measure and predict progress. We'll also look at information radiators such as task boards and burndown charts. We'll conclude by looking at how these concepts can be applied to complex situations such as fixed-date and fixed-scope projects.

• The problem and the goal.
• Story points and ideal days.
• Estimating the product backlog.
• Release planning.
• Multi-team projects.

Here’s a sneak peek into the course – the intro:

You can access the course at your leisure from any of the following devices:

• Any modern operating system with the latest versions of Firefox, Internet Explorer, Safari or Chrome.
• iPads and iPhones.
• Android devices.

(Javascript must be enabled.)

To learn more or sign up, click the URL in the intro above.

• They aren't additive. You cannot tell a boss you'll be done in 3 mediums, 4 larges, and 2 petites.
• Your view of an XL may not match mine. You may think it's 50% bigger than an L; I may think 25% bigger.

Teams get around both weaknesses with some underlying assumptions (hopefully stated) about size. They may, for example, state, “Let's call a medium a 5 and a large a 10.”

The primary advantage to t-shirt sizes is the ease of getting started. If a team needs to start with t-shirt sizes, that's fine. Later, though, that team will be better off using numbers directly. I might forget that an XL is 33% bigger than an L. I won't forget that a 10 is twice a 5. (If I do, the team has a different problem!)

T-shirt sizes can be a great way of becoming accustomted to relative estimating. So, start with them if your team finds that easier. But minimally put some underlying numbers on them (e.g., Medium=5) and then gradually shift to using the numbers directly.

I grew up in Los Angeles during a time when UCLA (University of California Los Angeles) was the dominant college basketball team. As a kid, I would have wanted nothing more than to have played basketball there, especially for their amazing coach, John Wooden. Somehow my 3” vertical leap and complete lack of coordination nipped my basketball career in the bud.

But it never stopped me from admiring Coach Wooden. He would have made a great ScrumMaster. My favorite quote from him was, “Be quick but don’t hurry.”

Isn’t that a perfect motto for Scrum teams? Scrum teams need to go fast but always with an eye toward quality. They need to go fast but not so fast they create technical debt. They need to be quick but should not cross the line and make mistakes. They need to be quick but should not hurry.

“Be quick but don’t hurry” was not Coach Wooden’s only Scrum-friendly advice. He was well known for creating what he called the pyramid of success, fifteen principles when combined led to success. He also listed what he called twelve lessons in leadership. Consider just a few of his lessons in leadership:

• Call yourself a teacher
• Emotion is your enemy
• Little things make big things happen
• Make each day your masterpiece
• The carrot is mightier than the stick
• Make greatness attainable by all
• Seek significant change
• Don’t look at the scoreboard
• Adversity is an asset

You can read the full list of leadership lessons and see his Pyramid of Success on the CoachJohnWooden.com website.

Leave a comment below and let me know if you agree Coach Wooden would have made a great ScrumMaster.

Oh, and Go Bruins!

But some projects should be preceded by an effort to decide what the project should entail and even whether there should be a project at all. This is the type of analysis work many teams put into a special Sprint Zero. While one sprint is often enough for this work, it's not hard to imagine a project large enough that it could benefit from a couple of sprints (albeit, usually short, one-week sprints). Although I think this is rare, I'd like to offer further advice on conducting such a "project-before-the-project."

A project-before-the-project can be more simply thought of as an analysis project. It may answer questions such as:

• What features would be delivered?
• About how long would it take?
• How much investment will be necessary?
• Should the project be undertaken?

On a project like this, there is no "potentially shippable product increment" in the normal sense of working software delivered at the end of a sprint. So, what then does a project such as this deliver?

To answer questions like this about what to do when applying Scrum outside its home territory of product development, I find it helpful to consider the reasons why particular Scrum rules are in place. The requirement to deliver a potentially shippable product increment exists to help Scrum teams avoid analysis paralysis and to feel a sense a urgency to produce something within the sprint. Just the right amount of urgency can generate greater creativity. The rule also exists to help Scrum teams stay honest--it prevents them from claiming progress when none has been truly made.

To see how these rules can apply on an analysis project, suppose a team is considering developing a new system for hospitals and is running one week sprints to answers questions like those above. At the end of a sprint, the team needs to be truly done with something. They can't be truly done developing a feature since they are only analyzing the system. But one way the team could be done with something is for them to have interviewed all the pharmacists who are stakeholders on the project. The team now knows everything pharmacists will need including new functionality relating to prescribing medications, looking up patient records, and so on. The team will not need to talk to pharmacists about their basic requirements again. They can be said to be done interviewing pharmacists.

Alternatively, the team could instead have talked to all stakeholders regarding their needs for the prescriptions part of the system. In this case, the team spends the sprint interviewing not just pharmacists but also some medical doctors, nurses, and so on. They don't talk to these stakeholders about anything but the prescriptions part of the system. They'll come back and talk to stakholders about other functionality in successive interviews. For now, though, this team can be said to be done analyizing needs of all stakeholders involved with prescriptions.

These examples illustrate how to apply the principles that underlie Scrum rules that can be a bit software- or product-development specific. While they allow a team to apply Scrum outside its home territory, I want to repeat my caution that I'd prefer not to undertake such an effort at all. Most projects can just start, with these issues resolved as the project begins.

I started a new project last month for which I'm the product owner. (You'll read more about it here soon.) This has got me thinking about product owners and wondering which one of these three quotes reveals who would be the best product owner:
 

“Never leave till tomorrow that which you can do today.” - Benjamin Franklin

"Never do today what you can do tomorrow. Something may occur to make you regret your premature action." - Aaron Burr

“Never put off until tomorrow what you can do the day after tomorrow.” - Mark Twain
Let's consider who would be the best product owner. Ben Franklin would have me prioritize as much as possible into today, or at least into the current sprint. That sounds good. We'll get more value into the hands of our users that way.

But what about Aaron Burr as our product owner? He makes a great point: If the product can get by another day without the new feature, why add it today? Something may change--maybe I'll think of an even better idea--and then I may regret my premature action.

Hmm, but Mark Twain goes Burr one better. Putting action off even further could reveal even more information, and more information could indicate a different course of action.

Sometimes action is called for--and we really should follow Franklin's advice to do today what we can. But sometimes a rush to act or to make a decision leads to the wrong result. After all, we are learning every day on our projects and some decisions deserve to be made tomorrow, when I'll be one day smarter. Or perhaps the day after tomorrow.

The concept of a "sprint zero" has become popular with some teams and so it is important to consider whether or not this is a good idea.

First, let's agree on the basic premise of "sprint zero." Sprint zero is usually claimed as necessary because there are things that need to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero.

One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product?

I find that many of these things that can be used to argue for the need for a sprint zero are really best thought of as things that happen in what I call the project before the project. Before a development project begins, there is often a project to decide if there should be a development project. Before a company begins a major new initiative, someone has to think about whether that initiative should be undertaken at all.

Making that decision can be viewed as a project.

Since Scrum works well as a general purpose project management framework, it can be used to manage the work of this project-before-the-project. During this project-before-the-project, the early team members (perhaps just a future product owner) can work toward creating an initial product backlog, finding or hiring team members, setting up the technical environment, and so on.

I find it helpful to think of this work as a project of its own because it is not hard to imagine this work taking longer than one sprint, the special sprint zero. What does a team using a sprint zero call their second sprint if they need one to do whatever work they've used to justify the special type of sprint? Is it sprint 0.5?

A couple of cautions are necessary at this point:

• Keep any "project before the project" as lightweight as possible. Most development projects do not need a project before they begin.
• Remain true to the principles of Scrum. A team participating in a project before the project will not be able to have anything potentially shippable. That's fine. But understand why having something potentially shippable is a central tenet of Scrum and apply that in a honest way to the project before the project.

I'll write more about this last topic--staying true to the principles of Scrum on a project-before-the-project--in my next post next week.

In case you still haven't gotten that perfect someone the perfect gift, I've got a couple of suggestions for you. Of course your significant other would love one of my books. And if you buy the Kindle version, they'll get it immediately so you won't be late with the gift or look like one of those people who waits until the last minute to shop.

Want an even better idea to tickle your lover's fancy? How about a license to my Agile Estimating and Planning video course? Cupid himself couldn't come up with a better idea than that!

And to make it easy for you, we're running a Valentine's Day-only sale. For one-day only you can get that course for half price. You can get a 6-month streaming license for $100 or a streaming+download license for $150.

Do yourself a favor--skip the romantic dinner, the flowers, the candy and all those other gifts. Get your signficant other what they really want: over three hours of tips on how to estimate and plan on agile and Scrum projects.

To get this special pricing, enter the code "valentine" when checking out.

I've also seen teams date-stamp their sprints. A sprint ending on 18 May would be known as the "18 May" sprint. Most teams doing this use the ending date of the sprint rather than the starting date of the sprint. Knowing how much time they have left is more helpful to teams than knowing when they started.

Still other teams will name their sprints. The name is a shortening of the sprint goal (which usually is fairly short already). So a team may have the "Shopping Cart Sprint" or the "Invoice Management Sprint."

One of the most creative things I've seen teams do is to forgo numbering, naming or date-stamping their sprints and instead pick a theme song for the sprint. The song, of course, has to have something to do with the work of the sprint. Here are a few of the sprint theme songs I've seen teams use and what they were for:

• "Time Is On My Side" by The Rolling Stones for a sprint focused on performance tuning
• "You Can't Always Get What You Want" also by The Rolling Stones. This was used ironically as the team was engaged in a multi-sprint effort focused specifically on features customers had asked for.
• "Turning Japanese" by The Vapors for a two-sprint effort to internationalize a commercial product.
• "I Ran" by A Flock of Seagulls for a team doing a bug-fixing sprint including fixing a couple of bugs that would crash the system.
• "Lola" by The Kinks for a sprint in which the team was attempting to give their customers "more than they expected."
• "Who Are You" by The Who for a team making big changes to their application's existing permissions subsystem.

Please leave a comment sharing how you like to identify your sprints. And if you pick a sprint theme song, please share an example of one you've used.