What good are story points and velocity in Scrum?

We use velocity as a measure of how many story points to take into the next sprint. When you take in enough stories, and story points, so that you reach your average velocity, then, you can end the sprint planning meeting.

Although this is a common approach, it is exactly how you should not use story points in Scrum. It leads to over-commitment and spillover (started, but unfinished work) at the end of the sprint. Both of these are bad for performance. How should you use story points in planning? How do you create the Forecast? And what do you do if the team runs out of work?

The first thing to remember is that Development Team is self-organizing. They have exclusive jurisdiction over how much work they take on. The Product Owner has final say over the ordering of items in the backlog, but nobody tells the the Development Team how much work to take on! Not the Product Owner, not the ScrumMaster, and certainly not the math!

As a Product Owner, I would use story points to help set medium and long-term expectations on what is really achievable. Wish and probable reality need to be more or less in sync with each other. If the disparity is too big, it's the Product Owner's job to fix the problem, and she has lots of options: less scope, simpler acceptance criteria, more time, more people, pivot, persevere, or even abandon.

As a ScrumMaster, I would use velocity to identify a number of dysfunctions. A wavy burndown chart is often a symptom of stories that are too big, excessive spillover, or poorly understood acceptance criteria (to name the most likely causes). A flattening burn-down chart is often a sign of technical debt. An accelerating burn-down chart may be sign of management pressure to perform (story point inflation). A lack of a burn-down or velocity chart may be a sign of flying blind!

As a member of the Development Team, I would use the estimate in story points to help decide whether stories are ready to take into the sprint. An individual story should represent on average 10% or less of the team's capacity.

How to create the Sprint Forecast

How much work should the team take on in a sprint? As Scrum Master, I would ask the team, can you do the first story? Can you do the first and the second? Can you do first, the second and the third? Keep asking until the team hesitates. As soon as they hesitate, stop. That is the forecast.

Why should you stop at this point? Taking on more stories will add congestion and slow down the team. Think of the highway at rush hour. Do more cars on the road mean the traffic moves faster? Would be nice.

Why do you even make a forecast? Some projects say, let's just get into a state of flow, and pull work as we are ready to take it. This can work too, but my own experience with that approach has been mixed. It is very easy to lose focus on getting things done and lose the ability to predict what can be done over a longer period of time. So I believe Sprint Forecasts are useful because they help us inspect-and-adapt enroute to our longer term goal.

What about "yesterday's weather"? Can we use the results of the last sprint to reality check the forecast for this sprint? Sure! If your team promised 100 but only delivered 70 or less, this is a sign that they should not commit to more than 70, and quite probably less. I call this "throttling", and it is one of my 12 Tips for Product Owners who want better performance from their Scrum Teams. But yesterday's weather is not a target, it's a sanity check. If it becomes your target, it may be holding you down.

What if the team runs out of work?

On the one hand, this is easy. If the team runs out of work, they can just ask the Product Owner for more. A working agreement can streamline this process, for example, Team, if you run out of work, you can:

• Take the top item from the product backlog.
• Contact me (the Product Owner) if you get down to just one ready item in the backlog
• Implement your top priority improvement to our code ("refactoring")

Implementing improvements from the last retrospective is usually a particularly good idea, unless you are very close to a release. There are investments in productivity that will often pay huge dividends, surprisingly quickly!

Are agile trainers agile?

There are literally hundreds if not thousands of people out there who will train you to do Agile (and some will even try to convince you to be Agile). Some of them are certified, some are not. How many of them apply Agile to their own profession? I believe the answer is "not many," and I have realized that I was not one of them. This a-ha moment help me refine the purpose of my CST mentorship program.

When people say "Agile", most people are referring to the four values of the Agile Manifesto. While these are important, I believe the fundamental definition of Agility is contained not the four values, but the first statement: We are uncovering better ways of developing software by doing it and helping others do it. (emphasis added).

I don't develop software, I train people to do Scrum. Actually, I like to believe I enable them to turn their current project into their best project ever, so maybe this "training Scrum" is too limiting. Hmm... let's not go overboard just yet! So what would my manifesto look like? Here is the first draft:

We are uncovering better ways of teaching Scrum, by doing it and helping others to do it! -- Peter Stevens

This has become the overarching goal of my CST Mentorship idea. Not just to get you through the TAC, but to create a community of like minded Agile trainers, who help each other to become better trainers, and help others to do the same.  It is no longer just a CST mentorship program, but a CST Mentoring Network.

P.S. I went looking for trainers who are active and transparent about mentoring. I have only found two (including myself):

• Daniel Gullo - see the section on the Gullo Protocols
• Peter Stevens - CST Mentorship Network

Does anyone else belong on this list? Please let me know!

Announcing: Scrum Trainer Mentoring Program

Do you want to become a Certified Scrum Trainer? Becoming a CST is long process which requires you to demonstrate both your knowledge of Scrum and your ability to teach Scrum to the satisfaction of the Scrum Alliance Trainer Acceptance Committee (TAC). Many trainers resist working with aspiring CSTs, out of fear of competition, lack of interest or lack of time. Until now.

After a couple of attempts on an ad-hoc basis, with both successes and failures, I believe the best way to mentor CST-aspirants is to lead them through a structured program. My goal is that by the end this program, you will be well qualified to teach Scrum and should be ready for the rigors of the TAC. I believe a structured mentorship will be a better way to achieve that goal.

My motto is partnership. I believe that future CST's and I can work together and we can grow together. And I have some ideas on how we can benefit each other. Interested?

1. Check out the CST Mentorship Program!
2. Contact me to discuss further!

An invitation to join a learning consortium

As many of you know, I have been working with Steve Denning, author of Radical Management, unofficial speaker for the Drucker Forum, and Member of the Board of the Scrum Alliance. His passion is about how management needs to reinvent itself to meet the challenges of the creative economy.

Steve and the Scrum Alliance are striving to build a Learning Consortium to explore the management implications of the emerging Creative Economy.

The members of the Learning Consortium will select five organizations from among these submissions and organize one-day site visits at their locations. Each host organization will make presentations and hold discussions about what it is doing, how it is doing it, and what it is learning. Membership of the consortium is limited to 30 organizations.

Each organization will be invited to send participants on the site visits. Once the site visits are complete, Scrum Alliance will organize a conference at which the Learning Consortium will make presentations and hold discussions about what has been learned. The Learning Consortium will produce a report of the conclusions of the visits and its review. The report will be made available to the 30 organizations.

Could your organization want to be one those 30 companies?

Are you curious? If so, please contact me, and I will be happy to put you in touch with Steve! Or here is more info:

• Steve presents the idea on Forbes.com.
• You can find the full concept on Steve Denning's website.
• You can find Financial Times columnist Andrew Hill's article supporting the idea online (paywall).

Could someone in your organization be interested in participating? If so, please drop me a line! And I will be happy to put you in touch with Steve directly.

EDIT: fixed missing links, formatting.

What does it take to be a good Scrum Trainer...

... and, who would like some kind of training to help become one?

The Doctor: Am I a good man?
Clara: I don't know. But I think you try to be and I think that's probably the point.
The Doctor: I think you're probably an amazing teacher.

This year, I have my second full year as a Certified Scrum Trainer behind me. Looking back, it seems the first thing that happened after becoming was a CST was getting a steady stream of requests from aspiring CSTs to co-train with them. I held off the requests until this year. I have now worked with four aspiring trainers. In each case, I learned a lot and have come to appreciate both the value and the limitations of the mentoring system. I want to create a workshop for aspiring Scrum Trainers, so that they can rapidly achieve the level of a good CST.

What does a good trainer do?

In my eyes, the purpose of a Scrum Master course is not to teach people the basic mechanics of Scrum. You can learn that from a 10 or 12 page document. The purpose is to enable the participants to discover a new, better, and more fun way of working, and leave them inspired to take that vision back to their companies to make it a reality! And they should have enough hands-on experience to have confidence and enthusiasm while getting started.

Just as Morpheus could only lead Neo to the door, but Neo had to choose to pass through, the job of a Scrum Trainer is to offer people that red pill. If what they learn resonates with them, they will want to plunge down that rabbit hole and explore it for a long time to come!

How do you train that? I believe that being a good trainer is a mixture of passion, attitude, skills and experience.

Passion

If there is one thing that can't be taught, it is passion. On the other hand, passion is contagious. So I try to give participants the opportunity to feel my passion and understand why I am passionate about Scrum. I believe sharing stories and learning by doing are the only way. As a Scrum Trainer, you need to be able to tell inspiring stories and facilitate great experiences.

Attitude

If you teach inspect-and-adapt, you have to do inspect-and-adapt, otherwise it is not authentic. (And sooner or later, you won't be very good, compared to others who do.)

I thought I was a pretty good trainer when I started. (Actually, I thought I was a very good trainer when I applied, which probably slowed my application tremendously.) Shortly after I started teaching certified courses, I noticed my Net Promoter Scores were not what I thought they should be. I also realized that despite collecting feedback from participants since my first course, I had never actually implemented a suggestion based on that feedback!

I wasn't inspecting and adapting, so I resolved to start. Since that moment, I read all the feedback. After each course, I strive to implement at least one suggestion or address one issue in the next course. I also send a follow-up to my participants with a summary of their feedback, and if possible, tell them what I plan to do differently in the future thanks to their feedback.

A funny thing happened. After an initial and substantial improvement, it got harder to improve. In some cases, I even regressed. But I didn't stop, even as I suffered some low points. Some issues were really hard to solve. I knew what the problem was, but didn't know how to solve them, even as I heard, time after time, that I needed to do something about it.

My willingness to adapt actually made it easier for me to change when the time was ripe. By always looking at how my customers were dissatisfied, I knew what needed to be done. Sometimes it took a while, but when I saw the solution to my challenges, I was able to implement them right away! (Thank you to the trainers and co-trainers I have worked with this year: Lizzie, Hugo, Elena, Niranjan and Andreas. Each of you has helped me move forward in important ways.)

The jump in my Net Promoter Scores was immediate and has been sustainable. I don't know if that qualifies me as a good trainer, but I am certainly better than I was two years ago, and it is the inspect-and-adapt cycle of Scrum which enabled me to get here.

How would I summarize the right attitude? A willingness to inspect, adapt and collaborate. How could you train that? Again, I think learning by doing and experiencing a-ha moments is the way to go.

Skills and experience

What else does a top trainer need to know? I believe a CST-level Scrum Trainer should...

• embrace the Agile Mindset
• have a validated deep understanding of Scrum
• have a validated understanding of what is not Scrum
• know how to teach so people learn.
• be able to teach any relevant topic spontaneously without powerpoint
• be able to tell authentic stories about their own experience doing Scrum to illustrate key points
• understand related approaches, e.g. Kanban, Radical Management, Lean Software Development, Extreme Programming, and how they relate to Scrum
• understand effective approaches for change leadership, e.g. Leadership Storytelling, Working Agreements, and how they relate to Scrum
• understand current vs. deprecated Scrum and agile practices
• be able to work with very large groups effectively

A Scrum Alliance Certified Scrum Trainer also has had their understanding, ability to teach, and course materials validated both against the authoritative Scrum literature and the understanding of Ri-level practitioners in the community. A CST candidate should be well prepared for the Scrum Alliance TAC (Trainer Acceptance Committee) process.

Next Steps

This is a work in progress. Two questions:

1. Have I captured the right vision for a good trainer? What's missing? What's excessive? What's just wrong? Please leave a comment!
   
   
2. Is there interest from aspiring Scrum Trainers for such a training? Do you know anyone who would be interested in attending some kind of workshop (webinar? combination?) to become a better Scrum Trainer or have an easier time with the TAC? If so, please share this article with them and invite them to start the conversation on my contact form.

Update: I realized that the form workshop was too limiting. Maybe a webinar, or a combination might be better, as it could be a) more long term, less geographically fixed.

How many people do you need in your team?

How big should your team be? It depends on what your goal is. In my classes, I have been showing the relationship between project size, cost and calendar time forever, based on research I had read, but could no longer find. Well, I think I have found the source, a 2005 paper from Team Size can be the Key to a Successful Software Project.

How big should your team be? Well it depends on what your most important goal is:

1. If you are trying to keep costs down, a team size of 3 people or less is optimal.
2. If you are trying to get a result as quickly as possible, a team size of 5 to 7 people is optimal.
3. If you are trying to hit a budget or deadline as accurately as possible, again a team size of 5 to 7 people is optimal.
4. If you are trying to burn a large budget, team sizes of 9 and up are best. These effects appear to be exponential.

Is item 4 really a goal? Nevermind. Silly question.

I think this data explains the Guidewire approach of keeping teams between 3 and 6 people. In effect, this has them cycling between lowest cost and fastest delivery, which is probably a sweet spot to find yourself in.

OTOH - This study is largely based on waterfall projects. Does anyone have the data to create a similar study of agile projects?

Why are you doing Scrum?

I am often asked questions like, "What do I do in Scrum when my team is spread across three locations?" My answer is usually something like, "you will suck." "Don't tell me that! That's insulting! I have to do that." At this point, I smile to myself and think, "that may be true, but you will still suck."

Why do I have conversations like this?

Last week, a got a question about electronic task boards. I could smell another one of these 'yes, but' discussion starting, so I chose to answer the question with a question: Why are you doing Scrum? I drew this picture on a flip chart and invited the participants to put dots on the location corresponding to their (organization's) goals:

Most dots were to the left of middle, the low performance choice, which explains why people did not like the high performance answer.

Scrum is based on the patterns of the 95th percentile of project performance, i.e. those awesome teams that are 3 to 10 times more effective than average. Those patterns are probably the same patterns as you experienced in your own best projects!

So why are you doing Scrum?