Monday, February 16, 2015

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!


Sunday, February 8, 2015

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):


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


Tuesday, February 3, 2015

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!