Attending a two day Scrum Master training by Jeff Sutherland & Serge Beaumont , I was drawn a very thorough picture of the success of the Scrum process . They proved from international & large longitudinal studies that teams doing Scrum were hyper-productive, swarming around topics and were feeling awesome. Who wouldn’t want that in their team? So back to the office as a Certified Scrum Master and do better Scrum, now!

Of course, the question is:
How to improve the Scrum process in an existing team?

I will share 4 insights and subjects in which we improved our way of working. If you want a short reminder about what Scrum is and it’s terminology, read this: http://www.scrumguides.org/scrum-guide.html first.

1. Estimating : At first nobody knows what a storypoint means. And it’s OK.

So how do you start estimating your tickets? Nobody knows the value of a storypoint ( SP ) and/or the team’s velocity. I think many teams feel uncomfortable with not delivering by underestimating stuff ( we do, I know for sure). So how to improve it?

One of the essentials of Scrum is that you don’t look at what a team thinks it can do, but measure what it does. So starting out is simple: assign a value of 3 points to a simple, known task A. The the question for estimation will be : “how much more work is this task compared to task A”. After a few sprints, the teams knows pretty much how much points they can do in a sprint and it will be based on their actual capacity. I carefully say “work”, because the work is something else as the time it takes to complete the work itself.

2. Why it’s hard thinking in Storypoints instead of hours when estimating work

People tend to think about work and hours in a 1 to 1 relation. We work 40 hours a week eg. But the amount of work I get done in this time will be different then the work my direct colleague get’s done. The difference in our skills will make me do a task slower then him, but the work is the same. The purpose of SP is to define the amount of work, so later on, the team can measure the time it will take them to complete the work as a team.

There is a nice comparison of SP with the height and width of an elephant : In general, a taller elephant may be heavier than a shorter one, but this is not always the case. There is no biological proof of a weight-versus-height formula, despite the common perception that more height means more weight. The same explanation applies to story points versus task hours: In general, a more complex user story (higher points) should take more hours to complete, but there are always exceptions.

In short: SP’s gives an indication of the amount of work, which does not say anything about the time it takes to do this work. We still have to repeat this truth to each other now and then.

3. Protect your sprintgoals, whoever tells you whatever

One of the reasons Scrum is successful is because it puts control in the hands of the people who will actually do the work.
In the Scrum process the Stakeholders suggest topics/features and their value to the Productowner(PO), who will fill and prioritize the backlog.
During planning, the team decides how many tickets they will take up from the backlog in the next sprint. Of course they help the PO to estimate the amount of work beforehand and do suggestions about which stories add most value.

Management is usually a stakeholder, and thus, in a classical way, not able to directly influence the work the team does. It makes the team “own their work” and thus commit to it. It also comes with to responsibility to protect the sprint and make it successfull. The challenge here is to gently tell stakeholders & management to go to the PO when they come in to reinforce importance on a not scheduled or unclear user-story…

4. What about bugs and new tickets?

The most disturbing thing for a team is ‘tickets showing up’ during a sprint. So we agreed on only adding a ticket to a sprint if:

• It’s a blocker, a non functional product for our users.
• All tickets from the sprint are done.

This means saying “nope” again to all those lovely users, dropping in and asking “could you do A and B for me?”. It’s a challenge since our primary users are in the same office as the team.

The simple rule: never work on something that’s not on a ticket, does give some rest and guides to the team. So if it’s not in the first day of the sprint: it’s out.

But what about Bugs?

To deal with bugs & blockers, we have a bug-buffer on our board, that has no subtasks at the beginning of the sprint but has some points assigned. It’s used to log the bugs on. So even when we’re fixing bugs, we don’t work without an already added a ticket with a value.

Because of this, we’re able to track time and follow our burndown properly. The big advantage is that if we’ve used our buffer, we can already update the PO that the scope of the sprint is probably being affected. Protecting our sprintgoals as a team.

That’s it for now.
What improvements or tips do you have for successfully improving Scrum process?