December 2014

100 day saving for Scrum?

In the last post I shared some of the pains I have experienced with scrum. I’ve been reading up recently on kanban and scrumban in a bid to reduce some of those scrum pains. Here’s some changes that could address those pains …


The product owner should still maintain a well ordered backlog – the item at the top should be the most important thing to do next. Super urgent stuff should go to the top of the backlog when it comes in.

Swim lanes

Items from the backlog should progress through the development life cycle through a kanban board consisting of the following lanes.

  • grooming
  • grooming done
  • dev
  • dev done
  • testing
  • testing done
  • review
  • release ready

Small bits of work

So, a feature should be taken from the backlog into the grooming lane where a member of the team will fully gather the requirements and design the solution. The solution could equate to a big chunk of work though and one of the things I like about scrum is that it encourages you to break bits of work up into small pieces. So, when the solution is designed, the work should be broken up into chunks of no greater than one days worth of effort. Those broken up chunks should then be put in the “grooming done” lane.

No planning

There will be no sprint planning. Developers should pull work from the top of the “grooming done” lane. Testers should pull work from the “dev done” lane.


Estimation is done during grooming – we have already said that items should be no greater than one days worth of effort in the “grooming done” column. So, a time estimate could be done at this point.

WIP limit

A work in progress limit should be set on the “gromming”, “dev”, “testing” and “review” lanes. This should help throughput and lead times.

Daily stand up

I’m not sure about the daily stand up – the team should communicate ad-hoc as necessary to remove blocking issues and the kanban board should clearly show what is being worked on. The lead dev should still keep an eye on the overall flow of work and deal with any bottlenecks and as a result may call a team meeting but that meeting should be much more focused on the problem at hand.


When a feature has been tested, it should be reviewed. A meeting could be organised once a week to go through the items in the review lane. Alternatively, videos could be recorded on each feature and shared with the stakeholders to drive feedback. The video approach may work better for distributed operations – e.g. when sales are out and about selling most of the time.


A version should be released when there is just enough value in a release. When starting a new release cycle, the product owner should identify a check point in the “scoping done” lane where there is enough value.


So how do we predict when a release will be done? We have our check point in the “scoping done” column as the release marker. We have a time estimate on each item in the “scoping done” column. So, we can just total that time up to help forecast the release date.

100 days saving?

In the last post I said that a scrum team of 7 could spend 2 days on sprint planning in a sprint and a further 2 days in daily stand ups. Totalled up for a year is just over 100 days. This approach removes those planning and stand up sessions. So, will this approach really save 100 days of effort in a year?

Scrum Pain

In the previous post I went through what I liked about scrum. I have found parts of scrum painful though …


Sprint planning is usually a 2 hour meeting at the start of each sprint to decide what work needs to be done and who is going to do it. The whole team is included in this meeting, so, if the team contains 7 people then that can equate to nearly 2 days of total time. The thing I struggle with is do we get 2 days worth of value from that meeting? If we have a well ordered backlog, why should it cost 2 days to work out what needs to be done and who should do it?

A sprint rarely goes to plan anyway. Estimates are always a little out, resulting more often than not in work rolling work over to the next sprint. Unexpected unplanned urgent work also comes in to the sprint. Of course you can have a buffer in the plan for underestimation and unexpected work, but that isn’t ideal.

I really do struggle to justify the investment of sprint planning.

Daily stand up

Everyone already has a good idea what everyone is doing – that’s what the sprint planning session was for and that’s what products like JIRA are for. As a developer, if I’m blocked by something that someone else on the team is responsible for, then I will communicate with them there and then – I won’t wait for the daily stand up.

For a team of 7 spending 15-20 mins in this meeting every day equates to roughly 2 hours per day which is well over 2 days in the whole sprint. Again I struggle to justify this investment and another meeting that interrupts developer flow.

Story pointing

People inside the dev team have difficulty understanding what a story point is – they naturally want to equate it to time. People outside the dev team have difficulty understanding what a story point is – they want to equate it to time! So why not just estimate in time?