The ScrumMaster Tales

This content is syndicated from Agile Pain Relief » Blog by Mark Levison. To view the original post in full, click here.

I’ve been struck how little is written about being a great Scrum Master. There is heaps written about Scaling Agile and a lot of great Technical books, but very little on playing individual roles well. The ScrumMaster Tales are intend to fill this gap.

Cast of Characters

ScrumMaster John – he’s been in the software industry for over 10 yrs. He’s been a developer and sometime development manager. Recently he’s been “promoted” to ScrumMaster and was sent on Certified Scrum Master Training but has no practical Scrum experience. Product Owner Sue – she’s also new to Agile. Unfortunately she hasn’t had training yet, although she has read a few books. She’s open minded, but a little confused about what needs to be done. Sue has 15 yrs experience doing Product management. The Application– I tend to use Amazon in many of my examples because most people know it well. Cast your mind back to 1995 when Amazon was first launched. Our team is building the original Amazon. I will introduce other characters as the tales evolve, onto our first story...


John is preparing for tomorrow’s Sprint Planning session, he asks Sue to show him the product backlog. She sends him a spreadsheet and boom he’s surprised.

  • As a user I want to search Amazon to find some books

  • As a user I want to buy a the book that I’m currently looking at

  • As a user I want to search using the author first and last name fields along with the title field

John panics and his jaw drops, he thinks the team can’t possibly have a sprint planning meeting tomorrow.


What problems do we face here:

  • The stories are awfully large (much larger than can be completed in a sprint),

  • The stories have generic users

  • They lack value/why statements

  • In one case the story is awfully specific about the implementation.

  • None of the stories have estimates associated with them

  • It’s the day before the Sprint Planning meeting and only now is John is discovering the problem.


So what options does John have?

  • He could work for the rest of the day with Sue to rewrite and split the storiesbut that still wouldn’t get the stories estimated

  • He could cancel the Sprint Planning session and delay the start of the Sprint. The backlog is ill prepared but Sue is new to Agile and appears to be trying to do the right thing. Cancelling Sprint Planning is an awfully strong signal to send at this stage of the game.

  • He could turn tomorrows Sprint Planning meeting into a Backlog Grooming (to rewrite and estimate the Stories). After that’s complete hold traditional Sprint Planning after that. This seems like the best option, but…

Before he takes any action John should sit down with Sue and discuss the problems he sees. All the while making the focus not mistakes Sue has made but instead focus on the backlog and what a good story would be. Then he should explain the current state of the world to the team, including all the options that they have. Then let the team decide what to do. Even if they make what John perceives to a weaker decision they will learn from the mistake and grow. What options did you consider for John? What could he do differently?

Leave a Reply

Your email address will not be published. Required fields are marked *

one + eighteen =