At Turtle Entertainment we are employing scrum for over a year. We have three teams each having one dedicated product owner. By a lot of very valuable help from bor!sgloger the teams are working synchronized since the beginning of 2011. All three teams take part in a combined planning and review meeting. This was a great improvement because now we can proceed very efficiently on the company backlog. But yet we are facing the consequences of forcing teams to work together in a highly efficient process.

Why improve quality?

Team synchronization enforces the teams to work together. Also our product owners have to form a team. This unveiled a bunch of problems to us. These problems existed a long time before but became visible now:

• The isolation of teams was close to total. They did not talk to each other. So knowledge got stuck at a team for example: How does our testing system work? How do I test most efficiently? – Only one team had the answer and they did not share it.
• Product owner of team A could not explain a story to team B. And vice versa team B was not able to understand product owner A.
• The product owners tried to go against the lack of communication by writing more “precise” stories. Eventually the stories were to detailed so they were not negotiable anymore. The stories did not comply with the INVEST model.
• The new synchronized stories were estimated unrealistically. Comparing the sum of story points to our velocity told us that the whole backlog would be done in one sprint. This was totally unrealistic.
• Due to the unrealistic estimations we are not able to plan what put our company backlog meeting in jeopardy.

These problems are dangerous to our efficiency they reduced the reliability of our scrum process and last but not least they bear down our teams motivation.

The root cause is easy to identify: There is no flow of information between teams & product owners, teams & teams and product owners & product owners.

We need to fix this fast.

What do we need to do?

Our measures:

• Transparency – We want more discussion of stories upfront. So we need to start to discuss the stories really really early at the beginning of the writing process. We need to make the writing process a transparent part of the scrum process.
• Guideline – Next we need a guide on how to discuss a story. What is important? What needs to be discussed next? When is the story ready for the selected backlog?
• Location – We need a room which encourages discussion and enables creativity.

Scrum teams discuss a user story with the product owner (dressed as Mario?! It’s Carneval :-))

How to do this?

Transparency:

• Get rid of excel files owned only by one specific product owner. We want all the company backlog in one simple powerpoint file. The product owners can keep their backlogs but they need to pitch their new ideas to our management which then puts them into the company backlog. As off there the story only exists in the powerpoint file and gets removed from the backlog.
• Product owners start to talk about theme-sized stories with the teams. The product owners are responsible to log the conversation between team and product owner. The scrum masters must push their teams to discuss the stories on a regular, reliable basis.

Guideline:

• Since we are very inexperienced in discussing user stories we need guidelines to help us. This guideline is a “Definition of done for a user story” giving the answer to the question: “Is this story ready for the selected backlog yet?”. A check list is appended to each story so one can easily see the progress of the conversation. At a glace you can see if this story is doing good or not so you hopefully are encouraged to about the story.
• We can later introduce a “Level of Done” for the story writing process which helps us with transparency also.

Location:

• The discussion itself must be made transparent. Having three teams it is not possible to have all members discussing one story at the same time. But all members must have equal chances to know what the other teams or product owners said about a story. So we must go for a asynchron discussion by writing on sticky notes and pin them at a story. Take a look at the photos to see this in action.
• The room where this discussion happens must not be a scrum space or meeting room. We want a living, open and ongoing discussion and even brainstorms and other creative methods should be applied. This leads to the thought of a cosy, relaxed location with enough space and creativity tools like whiteboards, flipcharts, pens in different colors and colored sticky notes.

Summary

At the end of the day we take a bit of team building and mix it up with a lot of transparency to achive better user stories. Nearly no formalization is needed, except for the check lists and user story done definition.

I think this is a good, noninvasive extension to the scrum process, which will be accepted by the teams and product owners very fast. It will take some time until we have the user stories rewritten and discussed as supposed. The (hopefully positive) effect will be visible next month.

 Files:

• Done Definition of a User Story
• Feedback Guideline
• Backlog (German only)

Since the beginning of 2010, we’re using Scrum to manage our development projects.
Last month we were able to welcome members of other departments to the team – including IT Operations, Community Management and Marketing – for the first time.

The team decided to use Post-Its for their work units in order to easily visualize the progress they were achieving during the sprint.
This lead, among other oddities, to tickets like these here:

Can’t read anything? You have no clue what you would need to do to finish these work units? That’s what the Scrum team experienced as well.

In the Sprint Retrospective Meeting the team decided to enhance the informative value of the tickets and their readability, by designing a layout for these pieces of paper.
It clearly states what information has to stand on what position on the ticket, and led to a digitally available layout:

The “Notes/Dependencies” part has been defined as optional, it can get folded behind the main ticket part.

If this is of any help for you, you can download the Open Office Document here (Sorry, file is missing).

My personal opinion: Great team work enhancing the productivity with a simple change of the method after only one single sprint has been finished.