5 Practices Better to Change in Your Scrum Implementation

Scrum saw a big increase in adoption last year. Everyone who is doing Scrum, does it differently as Scrum is a framework, not a process. One needs to inspect and adapt, mostly through retrospectives and daily improvements. I’ve been an agile proponent since learning about XP in the 90s and had the chance to learn something about Scrum in the last years and positions.

It is hard to determine if someone is really doing Scrum, the famous Nokia test helps as a Litmus test. Jeff Sutherland writes:

In 2005, Certified Scrum Trainer Bas Vodde was coaching teams at Nokia Networks in Finland and developed the first Nokia test focused on Agile practices. He had hundreds of teams and wanted a simple way to determine if each team was doing the basics.

I’m certain Scrum needs to adapt. As I’m head of development at a startup, and a ScrumMaster, I had some canditates for a Java job and they’ve asked me about Scrum. I’ve told them we aren’t doing Scrum by the book. They’ve been suprised and thought we do Scrum-Butt:

Scrumbutt is a word for the organisations saying or at least thinking that they are using Scrum, but the fact is that they are only using parts of the method. It is when a user of Scrum is saying: “YES! We use SCRUM, BUT we have these deviations in our method…”

But there are two sides beside Scrum. Doing not enough Scrum – ScrumButt. And learning from Scrum and going beyond – especially more lean. I think we are more lean and beyond basic Scrum. How did I adapt Scrum?

1. No Review Meetings

Scrum has a review meeting at the end of each sprint to present the work done to all interested parties.

What we do: We have no review meetings. Reviews with customers/product owner are done right after a story is completed together with the developers.

Pro:	Con:
Completed stories can go faster into testing Completed stories can be deployed faster and go live earlier	It’s harder for other stakeholders to see the stories It’s harder for the team to promote it’s work

2. No estimation of hours

Scrum estimates the hours remaining on each task card for each story. Those estimates are updated each daily scrum and drawn on a burndown chart.

What we do: We do not estimate hours.

Pro:	Con:
Less work to do, so less time wasted on something which is – often – not needed, less waste Updates of hours are done by one developer and therefor are more inaccurate	Harder to see if the time remaining in a sprint matches the work remaining Developers are not bound by their hour estimates and tasks may take longer

3. No hour burn down chart

In Scrum remaining work in hours is drawn on a burn down chart.

What we do: We draw two graphs, story points remaining and tasks remaining

Pro:	Con:
Less waste, as it’s easier to count SP and tasks than hours Graph of tasks remaining shows if the sprint goal can be reached or if the team is behind Story points remaining show that a team finishes stories too late in the sprint	Harder to see if the time remaining in a sprint matches the work remaining

4. We do not use Velocity for Sprint Planning

In Scrum some teams use the past velocity for planning the number of stories for the sprint.

What we do: We pull stories from the backlog. After each story was discussed during planning, the ScrumMaster asks the team if they can do this story in the next sprint. Go on until they say no.

Pro:	Con:
Developers are not fixed on a number and therefor are more likely to improve Velocity should increase in teams, if retrospektives are effective. So why focus exclusivly on past performance?	Because they are more aggressive with what they can do, developers may overestimate their abilities

5. We split the backlog into stories that are in planning and those that are ready for development

Scrum has a product backlog with stories and most of the time estimations. They are ordered top to bottom according to business value.

What we do: We add (at least) one more state. All stories which are ready for development are put in a “Ready” queue.

Pro:	Con:
The team sees which stories are ready for development The company sees if the ready queue is too large or grows too fast	More work for the ProductOwner, possible additional waste

I hope one or two things on the list get you thinking about your Scrum implementation and helps you to smooth your process and increase customer satisfication. What changes to Scrum have you applied? I would be interested to hear, please leave a comment.