Scrum and human behaviour – a hand and a glove – Part 1

Scrum, Agile and Lean techniques all make clear that Respect and Trust are necessary conditions for success. What is less mentioned and understood is how Scrum and Agile techniques create and engender this trust, and more so, does it in such a way that those being “manipulated” to trust and respect do not even realise what is going on.

To understand how Scrum and Agile techniques achieve this, let’s look at some of the planning and co- ordination events within Scrum:

• Prioritisation
• Estimation
• Sprint commitments
• Daily stand-up

In Part 1 we give a brief overview of Prioritisation – parts 2-4 will cover estimation, sprint commitments and daily stand-ups

Prioritisation

When there are a number of customers providing input into a unified Product Backlog, and there is contention about what is done first, the technique used in Scrum and Agile is to play Planning Poker. Put simply:

• All interested parties assemble in a meeting room
• Each is given a set of Fibonacci series based planning poker cards – the same used for estimations
• Each presents their input to the Product Backlog – why is it worth doing?
• Once all have presented – voting starts from the top
• Business value voting –what we stand to gain if we do it
  • All members raise a card to score business value
  • The highest and lowest scores present their cases – why it should be done, why not
  • Vote again
  • Repeat usually maximum three times for adequate consensus, after which the senior makes a call (the designated Product Owner for the meeting)
• Business risk voting –what we stand to lose if we do not do it
  • All members raise a card to score business risk
  • The highest and lowest scores present their cases – risk high, risk low
  • Vote again
  • Repeat usually maximum three times for adequate consensus, after the senior makes a call (the designated Product Owner for the meeting)
  • Repeat for all of the Product Backlog
  • You now have the best consensus opinion on what priorities are

Repeating these meetings regularly to review priorities brings you closer and closer to the best possible set of priorities

Why does this work?

It works because:

• It is based upon the trigger class of strategies employed in repeated non-cooperative games from game theory
• Research shows that human and other co-operative species evolved to intuitively employ a tit-for-tat strategy in order to achieve more together by balancing co-operative, aggressive and defensive impulses.

The trigger strategy works as follows:

• Initially cooperate
• Punish the opponent if a certain level of defection (i.e., the trigger) is observed.
• The level of punishment and the sensitivity of the trigger vary with different trigger strategies.

What this translates to in business prioritisation where:

• there are non-cooperating or conflicting goals from the various business representatives present – be they business plans, product features whatever
• there are shared resource limits such as budget, time, skills, staff etc.

is the following:

• All press for objective presentation and evaluation of business cases
• Those that appear to vote on emotion or are overly partial to their own projects will be punished in the next round of voting

More information

• Trigger strategies                             http://en.wikipedia.org/wiki/Trigger_strategy
• Tit for tat                                             http://en.wikipedia.org/wiki/Tit_for_tat
• Evolution of co-operation            http://www.amazon.com/Evolution-Cooperation-Robert-Axelrod/dp/0465021212

Estimating Tasks or Not? The effect of value driven user stories…

One of the perks of having a scrum coach in house regularly, is that my mistakes hardly ever go unnoticed . We have a regular meeting during which we discuss our own scrum implementation in Kaizania, and how we can improve the way we work. For me, this is one of the best things about scrum: you have never “arrived”, and can’t settle into a comfort zone, there is always something which can be improved!!

We had a meeting about a week ago, during which Arrie pointed out some things which we need to sharpen up on, one of which was the fact that we currently size our tasks, not only the stories as we’re supposed to. Now, even though I know it isn’t supposed to be done this way, we did it with good reason, and after having the discussion with Arrie, he understood the purpose of this, and left it at that.

The reason behind the unruliness was that we needed to size our tasks, as the stories took longer than a day to complete, sometimes up to 80% of the sprint duration, hence the burn down would be useless if we didn’t size the tasks. In the past we tried one sprint, without sizing the tasks, and it was chaos. The team attempted to estimate the work left during the daily stand-up, but their estimate was not even close to being accurate, and we ended up with a lot of work left two days before sprint end, even though the burndown chart indicated that we were well ahead of schedule.

To avoid running into that problem, we had the team size the stories during sprint planning, as it should happen. Afterward I, as scrum master, would divided the story size between the number of tasks, and so each task had a size as well (which made up the total points allocated for the relevant story). This gave us a much better indication of the progress made, and even though it wasn’t the perfect solution, it worked much better than estimating the amount of work left during the daily stand-up.

After my discussion with Arrie, we had a sprint planning, and one of the other areas which we had to work on was breaking our stories down. With blood, sweat, and some tears we managed to put together a complete sprint backlog with no story sized bigger than 13!! This was a huge improvement, as our previous sprints had stories sized as big as 89!!

Once we started doing the task breakdown, we realized that the tasks were much different than before, and there was no sense in sizing them anymore!

The problem was that with the bigger stories, we actually had an epic as the story, and the tasks were small user stories. During our first stand-up meeting, I explained to the team again how we do the estimation of work left, and this time around it went much better. Because our stories were smaller, the team was confident to size the work left, and this time around our results were much more accurate. Even more accurate than when we allocated a size to the tasks.

Danette Kok

Scrum Master

Kaizania