Story Points, Handling Multiple Teams, and More. Answering Your Questions

Recently I held a live ask-me-anything session on Facebook along with Brian Milner, the latest trainer to join Mountain Goat Software. Brian and I took questions for an hour and I wanted to share some highlights in today’s post. I’m including the video if you’d like to watch the whole session, and I’ve also timestamped the list of questions at the end of this article, to help you find a specific answer if need be.

 

5 Highlights of My Q&A with Brian Milner

I’m thrilled to add Brian to our list of instructors. If you’re looking for a Certified ScrumMaster® class, I highly recommend registering for Brian’s class starting next week. He’s a great coach with more than 25 years of experience in his journey from programmer to Scrum Master and now Certified Scrum Trainer.

Brian and I took turns answering questions, and I’ve picked my five highlights below:

19:15

Q1. Can a full-time Scrum Master cover more than one team?

This was inspired by a post I wrote that asked the question: does a team need a full-time Scrum Master?

I wanted to include it because Brian and I didn’t agree on the answer. I enjoy having my beliefs challenged; you learn so much more when you don’t think you’re right all the time.

Brian started by referencing the common adage that:

“A good Scrum Master can handle two teams, but a really excellent one can handle one”

(Watch the video for the actual delivery…going live isn’t always easy, you know.)

Brian and I agreed that while the Scrum guide doesn’t say how many teams a Scrum Master can work with, there should be a limit.

We mildly disagreed about where that limit should be. Brian’s example of a poor Scrum Master handling seven teams is enough to give anyone a headache, and I agree that doing things properly for one team can be a full-time job for even a great Scrum Master.

But there may be occasions when working on multiple teams can work well, although success at this is going to depend on:

  • The amount of organizational impediments you need to fight
  • Inter-dependencies between teams
  • The skill and experience of the teams
  • The size of the teams

So where did we put the upper limit on how many teams one full-time Scrum Master could handle? Watch the video at 19:15 to find out.

28:54:

Q2: How do you resolve a situation in which multiple teams have separate definitions of story points?

One viewer wanted to know how to combine multiple team plans if each team is using a different currency.

To answer the question, Brian took a step back to ask whether rolling up all the team plans was even necessary. Sometimes it’s easy to get stuck trying to solve a problem that doesn’t actually need to be solved, and avoiding that is one strategy a good agile coach will teach. A coach keeps your team open to new perspectives and making progress.

Here’s a place to start: ask whether the teams are working on the same product. If these teams are working on independent products, there may be no need to combine plans at all.

And even if teams are working on the same product, it can be easier to let teams decide their own currency instead of trying to standardize units across the organization. Why? Because it’s very difficult for separate teams that don’t work together to develop a common and consistent understanding of a story point’s value. Brian highlighted this by using a great example from his classes about using zoo points.

In the past have used a technique I call creating a Rosetta Stone. This technique makes it easier for multiple teams to estimate with the same valuation of story points, and Brian and I agreed that is the key thing to achieve.

To hear about Brian’s zoo points and how to create your own Rosetta Stone, skip to 19:15 and play from there.

39:30:

Q3: How do you assign story points to series of similar stories when the stories are dependent on the first being built?

...For example having several stories such as: “As the X, I want to be alerted when Y.” The first story will take longer because we have to code the supporting architecture for the alert system, but the following stories will be easier once this is done? Do all stories have the same points?”

The way to think about this is to imagine you’re looking at a backlog of multiple items—say, 20 items, 50 items, a hundred items, whatever it is. Add up the story points on everything in the backlog. Ignore the fact that you perhaps haven’t estimated everything, but add up everything in your backlog. The sum you come up with should represent the real amount of work there is to do.

If doing the first item is going to take 10 times as long, that first item should have 10 points on it. Assign story points to the other items in a proportional way. To make the example easy, let’s make them really small, and make them each worth one point. Now we have one big story that’s estimated at 10 points, and the next 10 all have one point each, to total 20 points.

You want the sum of your estimation points to represent the real amount of work there is to do: 20 points’ worth. You’ve said that the small stories that follow that big one are dependent on the big one, but I wouldn’t estimate 10 for each item—because if I did, I’d add up those 20 items and see 200 points of work. That’s not accurate; there’s really only 20.

Now what might happen, and I’ve actually had this happen, is that we go to plan the sprint and the product owner sees that one 10-point story and says, “I don't want that one. I'll do the other ones that are only one point.”

Then it can feel like you’re moving the goalposts because the team has to say, “The one you picked is now 10 points.”

But you have to be firm and put the 10 points on whichever you’re going to do first. You might have to explain why to the product owner, but in my experience, most will understand this.

42:15:

Q4: Any advice about how to stop sprint scope creep? Is there an acceptable threshold for small changes that we should just absorb?

This was a quick question, but I pulled it out because I think it was a neat little discussion and I was interested in Brian’s thoughts, specifically about:

  • Does scope creep even exist if we’re supposed to be agile and respond to change?
  • During a sprint, what’s the difference between a change that should be rejected and one that we should accept?

44:55:

Q5: How do you encourage teams to embrace using video conferencing for Scrum ceremonies during this time when in-person communication is impossible?

This is a great question, and relevant to anyone who is still working from home or in a remote situation.

Watch the video to hear our experiences of video conferencing, including:

  • What I used to do on a conference call before the days of video
  • How to make people more comfortable before that first video call
  • How to deal with people who are not yet ‘at one with the mute button’
  • Where does being remote live in the Agile Manifesto?
  • Why the “invited to your house” premise is an excellent way to make people feel comfortable (I loved this idea from Brian)

If you were with us live, or if you watched the recording, I hope you enjoyed the session.

Don’t forget to check out Brian’s Certified ScrumMaster® class on the 20th July

For a full list of times and questions, just look at the list below:

  1. 5:10: How does a Scrum Master handle dependencies between teams?
  2. 8:50: What market trends are you seeing today in the job market? 
  3. 10:45: When teams work on sprint delivery and production issues, how do you commit to sprint deliveries effectively?
  4. 13:55: What do you do with a business that thinks of business analysts as product owners and vice versa?
  5. 14:40: How to form a cross-functional team with a wider variety of skills
  6. 17:50: How do you avoid interference from a project manager working on another project?
  7. 19:15: Can a full-time Scrum Master cover more than one team?
  8. 26:30: What is the future of the agile way of working?
  9. 28:54: How do you handle multiple teams with different definitions of story points?
  10. 34:10: What do you think of companies that try to mix and match roles?
  11. 35:45: How do you get decision-makers to not ignore the role of Scrum Master?
  12. 37:20: How do you deal with conflict between Scrum Masters and product owners?
  13. 39:30: How do you assign points to user stories when similar stories are dependent on the architecture of the fist story?
  14. 42:16: How do you handle sprint scope creep?
  15. 44:55: How do you get teams to embrace video conferencing for Scrum ceremonies when in-person isn’t possible?
  16. 50:10: How do you handle an organization that wants to implement Scum with a product owner, Scrum Master, and a project manager?
  17. 52:45: How do you handle a product owner who micromanages the team?
  18. 57:15: How do you handle horizontally assigned teams?
  19. 59:55: How do you handle the challenges of being a short-contract staff interacting with full-time staff?

Scrum Foundations Video Series

Scrum Foundations Video Series

All the foundational knowledge of Scrum including: the framework, values, different roles, meetings, backlogs, and improving efficiency & quality.

Watch Now
Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.