Skip to content

Scrum Puzzle #3

Well looks like everyone got that changing the sprint length is a bad idea. Here are the key learning points for me in Scrum Puzzle #2:

1. Velocity is not linear, all it tells you is how many points a team usually complete in a fix period. As soon as you change that period you no longer have data to make any prediction. You cannot assume that if a team do 30 points in 2 weeks, that they can do 15 points in 1 week. The team may for example do all the coding in the first week and all the testing in the second. So after one week they would deliver 0 because nothing is tested. I’m not saying this is how all teams work, or even how teams should work, all I’m saying is that knowing only the velocity for a 2 week sprint you cannot know anything about where the team will be after 1 week.

2. Velocity is not a commitment or a target. This is a common misconception. Just because the team delivered 30 points last sprint, doesn’t mean they will again. Velocity can be used to make a guess about what can be delivered but it does not make it happen. I commonly see Product Owners falling into old project management habits of making commitments based on guesses, and then making it the team’s responsibility when it is not delivered. If you start doing this, a range of undesirable effects start to happen. Please start to game velocity, teams unconsciously drop quality to meet the commitment, and business get used to having the sometime unreasonable demands met. It might seem okay to do this once, but it never only happens once. It takes courage to break the cycle, and to trust that the team will deliver the best thing they can, and to work with that.

Okay onto Scrum Puzzle #3:

You work in an organisation doing Scrum across multiple teams. You are one of the ScrumMasters. The development manager asks if you can work with the other ScrumMasters to have all the teams setup their boards in the same way, using the same colours to mean the same things, e.g. pink for bugs. He thinks it will help other people in the company understand the boards and therefore help with buy in to the Scrum process across the company. What do you do?

6 Comments Post a comment
  1. Dan #

    I’m not a ScrumMaster, so I could be way off on this, but that sounds like a bad idea. I’d expect the teams to already have an immediate understanding of what the layout and colours mean. Changing that means relearning, which is not in itself a bad thing, but in this case would seem to have no direct value for the team members.

    October 11, 2011
  2. mmm, my gut reaction is that the team owns the board and thus as it becomes theirs it will grow and adapt (including colors) to suit that team. I understand the dev managers situation though – it would be awesome if when others in the company walk into a room could understand easily what is going on.
    Making all the boards look identical (colors etc) is one solution. Another might be just to have a key up next to the board. In the example above – perhaps a blue sticky with the word BUG on it etc.
    Note: I have this situation at my current workplace, and our dev manager has repeatedly asked for this 🙂 We did try making everything the same, and it lasted about 2 sprints and the teams started making small changes that worked better for them, within 3 months all boards had slightly different colors again!
    What I have found works well – is that during the review we talk off the board – explaining the wall “art (story map, kanban board for bugs and the task board) – this continuous repeating has allowed people to understand our wall “art”.
    Going to put up a key for colors right now ….

    October 11, 2011
  3. Our rules are simple. When it has anything to do with scrum, we allow the teams to make the rules. Any manager be it DEV or BA does not have a ‘real influence’ on the way the scrum teams operate. So in a nutshell our teams own their boards and when changes are introduced, the scrum masters of the various teams, keep them all aligned.
    Currently we use specific colour stickies to indicate categories of work. eg green for expedites, yellow for business priorities etc. We also show dependencies across teams. When team members take work, they put their name on the specific task for the story and this currently works well for us.

    October 16, 2011
  4. I agree that the scrum board belongs to the team. However, If you are someone thats interested in how all the team are doing then you do want to have the ability to review the scrum boards of various teams at a glance.

    Having everyone do things differently adds confusion and in the end you don’t have the transparency that scrum should bring to a company. So I say standardize the colours.

    You cant have one team telling the CEO that we have 8 large T-shirt sizes to go before the project is delivered and another team saying 24 story points remain.

    I think I read in one of Mike Cohen’s books that when running multiple teams you should even try and get the estimation process the same so that an 8 in one team is an 8 in another. If you should go to that level of detail then it seems logical to have “blue” mean a bug for all teams. By all means let all the teams meet every so often to make this decision themselves, but as a SM or Coach I would try and ensure that the teams are agreeing to a standard and not all going off in their own directions.

    Problem solved. The teams meet to decide on a suitable standard and so therefore its not some manager saying “do this”, and the manager is able to follow the cards and colours across multiple teams.

    Thats my 2c worth. 🙂

    October 19, 2011
  5. I think the natural solution is to let Teams forge their own setup for their boards. Here are the reasons why:

    1. Scrum Teams are autonomous units by design and when you start to impose centralised control, you dilute the autonomy. You’ll have a hard time convincing the team that they are self-managing if someone starts dictating card colour, pen type and colour etc.

    2. Target Audience. Who is the Scrum Board actually for? Is it for the Development Manager? The CTO? The Office Cat? I’d say that it’s for the Scrum Team. I’d also say that managers and execs aren’t (and shouldn’t) be interested in the minutiae. They just want to know that it will be done.

    I understand the manager’s goal in that he wants scrum adoption to be more positive across the company. However, I’d say that the way to do that is to make the work and the results of the Scrum Team transparent, not the language they speak in.

    February 29, 2012

Trackbacks & Pingbacks

  1. Scrum Puzzle #4 | Coaching teams to do better scrum

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: