But, I've learned that means I'm ideal for writing a team's user stories.

Research by Daniel Oppenheimer and two colleagues found that fonts (such as my handwriting) that are hard to read lead to greater recall than fonts that are easy to read.

They gave a group of students two documents--one in easy to read, 16-point, black Arial; the other in hard to read, gray, 12-point Comic Sans. After distracting the students for 15 minutes, they tested their recall of facts in the two documents. They recalled 87% of the facts in the hard-to-read font but only 73% of the facts from the easy-to-read font.

From now on, I suggest having the team member with the worst handwriting write all user stories and be the one with the marker during all team meetings. And, if I'm on your team, that's likely me.

I also apologize that you'll immediately forget 27% of this blog post because of the nice readable font.

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.

Standard Scrum advice is that the daily scrum is strictly time boxed to fifteen minutes. Don’t dare let it go any longer than that. I want to share an example of how I sometimes have teams throw that rule out the window.

One challenge distributed team members face is getting to know one another. Members of a collocated team get to know one another through small talk. You and I get in the elevator together and ask each other innocuous but friendly questions: Do anything this weekend? How old are your kids now? and so on. This type of water-cooler conversation doesn’t happen with distributed teams.

Further, a distributed team’s meetings rarely have any of the playfulness that may occur with a collocated team. I’ve seen members of a collocated team hold up a rubber rat when another members goes too deep into a topic (referred to as “going down a rat hole”). Even if team members could do things like that when distributed, they often don’t know each other well enough to feel comfortable doing so.

As a ScrumMaster for a distributed team, I find it important to help team members get to know each other well enough that they can exhibit this type of playfulness. A great way I’ve used to do that is by starting each daily scrum with a bit of small talk--the type of conversation that happens naturally when collocated but won’t with a distributed team unless someone explicitly makes time for it.

I’ve gone so far as to tell teams that their daily scrums are required to start with five minutes of mandatory small talk. No mention of the project is allowed. Team members need to talk about their hobbies, what their kids did the night before, the great movie they went to, or things like that. After a mandatory five minutes of this, we start the normal part of the daily scrum, which is time boxed to a further fifteen minutes.

One of my favorite things to hear about during this part of a daily scrum is how team members in a different country will be celebrating a holiday. For example, on next Friday my friends in Norway will celebrate Syttende Mai, Norwegian Constitution Day. The first time I was on the phone with Norwegian team members and they told me they’d be off on May 17, I wanted to know what type of a holiday it was. Was it one of those holidays when you have a big meal with family (like US Thanksgiving)? Or was it a holiday best spent outside with friends (like US Memorial Day)?

Similarly, when on the phone with members of a London-based team I got to find out what Boxing Day was all about. I’d certainly heard about it despite living my whole life in the US. But I had no idea why the British were so anxious to put on boxing gloves and all fight each other. I also learned why they care about “bank holidays.” In the US, I’ve never cared when the banks were taking the day off.

I’ve learned about all manner of holidays from working with distributed teams this way. More importantly, though, I learned little details about the lives of my remote teammates. And that helped us all work together better. So, while I fully support a fifteen-minute time box to the daily scrum, for some teams, I will occasionally add another rule that we start with five minutes of small talk. I suggest you try it, I bet you’ll learn a great deal more about your remote teammates.
 

• 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.

On a consulting engagement a few years ago, the VP who had brought me had me start the day observing a few daily scrums. In each meeting I noticed the different ScrumMasters appeared to be taking very detailed notes. At lunch I asked the VP about this.

He told me that he’d asked all ScrumMasters to do this a few weeks prior. Each ScrumMaster emailed the notes to him and he combined them into a daily email to the whole company so that, he said, everyone could benefit. After he told me this, he added, “Funny thing, though. Those meetings aren’t as helpful as they used to be. Hardly anything critical seems to come up in them any more.”

I wonder why. Perhaps it was because “I’m going to be five minutes on the such-and-such task” gets turned into “Mike is late” in an email to the whole company.

I always advise ScrumMasters against taking notes during the daily scrum. If you do want to take notes, I recommend writing the note on a whiteboard or some place where everyone participating in the meeting can see what you write. I know I’m cynical but I often think people think the ScrumMaster is writing the worst possible thing when it’s written in private. The ScrumMaster might be writing “Get Mike some help on the such-and-such task” but I think she’s writing “Have Mike moved off the team.”

Taking notes on the whiteboard has the further advantage of letting anyone add to the notes during the meeting or easily refer to them later. If any notes are action items, they’ll be on the board the next day when any old notes can be easily erased. So, take notes in a public place, even if you’re making a note to move me off the team.
 

• 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.