Our blog

20 Sep 2016
by cvringer

Scrum Training in a Scrum way

At a company i work with, i’ve facilitated several scrum trainings.
In stead of the usual (boring) ‘sit and listen’ trainings, in this training, participants can determine the content themselves. Of course there are more intersting items then there is time for, (just as in the ‘real’ world) hence they have to prioritize what they want to learn this day. From those items, we create a backlog and we choose a Product Owner. Now we start with sprints. In every Sprint we deal with the topics defined in our sprint backlog. We use live examples and excercises to explain the theory. After every sprint, there is a sprint review with Product Owner, Stakeholders and team (we, the trainers) and a retrospective. Next we all decide if adjustment of the items is needed, and we plan the next sprint.

Of course it happens that we don’t finish all items in a sprint(just as in the ‘real’ world). We then decide together what to do with the remainin items. So the whol training is given using Srcum, with all scrum elements in place. At the end of the day, the students have done 4 to 6 sprints, in which they have learned the theory, and done scrum in practice. I recieve many enthousiastic reactions from this way of teaching Scrum, and the training itself is full of energy. A very energizing and fun way to do!

24 Feb 2016
by cvringer

Be aware of those extra lanes

Scrum board

You have probably seen them when you entered a team room. Scrum boards with well defined stories and nice task descriptions under them. But then there are so many lanes… Many tasks are in one of the lanes, but only a few are in the ‘Done’ lane. I’ve seen lane names like ‘peer review’ ‘testing’, ‘investingating’ and ‘blocking’. When i ask the team about the specific use of the lanes, the answers mostly boil down to handoff.

For example, when i asked for the use of the ‘blocking lane’, a team member told me that whenever he had to call someone to discuss an item, and that person wasn’t available, he would hang the task in the ‘blocking’ lane. And then he started with another task. When i asked him when he then would resume the old task, he said that the would try again after het finished his ‘new’ task. Sometimes the person to contact wasn’t available the second time, and then the task would wait for another cycle.

Handoff was also created in the ‘peer review’ lane. Whenever a team member was ready with his or her’s code, they would move the task to ‘peer review’. Those tasks stayed in that line for almost the entire sprint. You want to know when the peer review was done?… Indeed. At the very end of the sprint. Sometimes bugs where found, or refactoring had to be done, and there was stress. This stress also applied for testing. There was a separate ‘testing’ lane. Testing tasks where mostly done by one tester, and… at the end of every sprint.

So sometimes these extra lanes keep the team from getting stories done. There is ‘handoff’ in the team itself. If a team member starts a task, he should never let go of that task until it is finished. Every lane that releases the task from the responsibility of the team member is handoff, and will delay the execution of the task. Yes, i acknowledge the fact that sometimes it will include a lot of effort for the team to remove an impediment. But the focus should be on delivering the task as fast as possible. Starting another task without finishing your previous one, is ‘local optimalization’.

Introducing lanes is not bad by default. (After all, the team can decide to introduce lanes). But if a team introduces a new lane, it has to agree on keeping in touch with the task.

So be aware of those extra lanes.

25 Jun 2015
by cvringer

Relative mass estimating

Why relative mass estimating?

Scrum teams are often asked to quickly estimate new stories without knowing much details. How do you roughly estimate those “high level” stories fast, in let’s say, one hour?

Enter “Relative Mass Estimating”, also known as T-Shirt size estimation.

These roughly defined stories (or epics, or what you want to call them) can, for example come from a roadmap defined by the business. A high level description is provided, such as ‘Customer can view his invoices’, or ‘Customer can change his contract’, but no details are available yet. So the team should quickly decide were the data could come from, and which systems could be involved. Usually teams are very good at this, especially when they are long lived (feature) teams.

Relative mass estimating is done by the Product Owner, Scrum Master en the entire devteam.

The following rules apply:

  • We divide only in Large, Medium, Small. No stories in between;
  • As always: Estimates are estimates;
  • We estimate with the knowledge we have at this time;
  • We do not ask for detailed information;

The Scrummaster creates 3 area’s, which are called ‘Large’, ‘Medium’ and ‘Small’. I use just 3 labelled A4 papers, and put them on the floor.

Now the estimating begins. The Product owner explains the story shortly, and hands the story over to the team. The team has a short time to common understand what is asked. (If needed, a timer can be set). Then the team decides where to put the story. (L, M or S). The first story will probably the most difficult, but after that it will go faster. If the team cannot decide, you can use thumb-voting to force a decision. Sometimes the team can decide to re-arrange stories, because they got better insights or a story was estimated with wrong assumptions. There must be time for that. We did this workshop for one hour, and we relatively estimated more then 60 stories.

So what is the value of relative estimating, and what can we do with the results?

Our end goal is to estimate the number of sprints the story would take to build. This allows us to look further into the future and very roughly tells us when items from our backlog can be build. (We could use this in a burn-up for example). It also provides the Product Owner earlier insights about the realization of the roadmap, so he can shift priorities. After the relative mass workshop, the team can estimate one or two stories of which it is pretty clear what to build in ‘number of sprints’. Other stories in the same category will be assigned the same number of sprints. Another possibility is to T-shirt size each L, M and S again, to get more refined story estimates, and then pick one ore two stories to estimate in sprints.

© Keienberg Consultants