The Problem With Scrum

As a framework for managing a project Scrum is all about continuous adaptation, so why does the methodology itself seem resistant to change?

I am an agile software developer and have made Scrum the foundation of my company, B13 Technology , because of its continuous adaptability and flexibility to change. However, I do think Scrum is pre-occupied with an obsession with planning and monitoring.

What is Scrum?

In the mid 1990s the methodology that is now known as Scrum was born out of a growing discontent with the then popular Waterfall methodology. In contrast to Waterfall’s regimented approach Scrum was all about flexibility and adaptation.

In accordance with Scrum I completely acknowledge that, dependent on the client’s wants and needs, a project is always susceptible to change.  I do have a problem however, with Scrum’s obsession with sprint planning and daily stand-ups or ‘scrums’.

What is a Sprint?

In its most basic form, a Sprint is the measure of development within scrum and aids the development process by providing a framework (see Figure 1):

Figure 1
Figure 1

So what’s the problem with this?

The Sprint Plan is important – but I don’t think it requires all of the developers to be in a meeting for a whole day. For a team of 8 (6 developers (including 1 Scrum Master and 2 testers) the Sprint Planning would take 8 worker-days. If you include the Product Owner this goes up to 9 worker-days. At B13 Technology we do the sprint plan in a very different way.

What B13 Technology does:

  1. The scope and features of the sprint can be decided by the Product Owner and Scrum Master/architect in a meeting that takes a couple of hours. Total so far: 0.5 worker-days 
  2. These features can then be analysed by the Scrum Master/architect and split up into short tasks of approximately 2-4 hours. This stage involves the architect’s knowledge of the system and the tasks are broken down to a detailed level. This will take about 1 – 1.5 days, but can be done ahead of time before the previous sprint is complete to keep production going. Total so far: 2 worker- days
  3. Once these chunks of work are small enough they can be sent to the development team for accurate estimates. Each task is estimated only once by one developer. So for a two week sprint each developer is estimating around 80 hours of work, or 20-40 tasks. This should take about 0.5 days for each developer. Total so far: 5 worker-days
  4. Once the estimates are all in the Scrum Master/architect can go back to the Product Owner and remove low priority tasks that may not fit into the sprint duration. I find this is normally a 1 hour meeting. Overall Total is about 5 worker-days

This way of working cuts the time required for the traditional Sprint Plan in half. What’s important to recognise here is the time saved, time which the developers and testers can better use writing BDD scripts and test plans. Furthermore, the resulting plan is far more detailed than one put together by a room of people working on high level tasks one after the other. Here, each estimator is working on a much more in depth task in parallel.

Potential objections –


 “Estimates are better when the whole team estimates a task – planning poker.”sprint plan   person

Response: At B13 Technology, we look to improve estimates over time. Modern issue tracking tools make it very easy to spot where estimates are consistently inaccurate. This makes it easy to address the problem with specific developers and to help them improve estimates over time.


 “The Scrum Master shouldn’t be more important than any other developer”

Response: Maybe, but there should be at least one architect on the team who is most suited to planning the tasks in detail. If you can save nearly half the worker-days and end up with a more detailed plan, then maybe parity becomes less important. The team can and should be consulted on the most important design decisions. These can generally be thrashed out in a short breakout meeting.

The Scrum guideline asks three questions:

  1. What did I do yesterday that helped the development team meet the Sprint Goal?
  2. What will I do today to help the development team meet the Sprint Goal?
  3. Do I see any impediment that prevents me or the development team from reaching the Sprint Goal?

If you have a well defined and well thought out Sprint Backlog then the answer should be as clear as ‘I completed tasks 123, 567, and 789’.  The answer to point two should be: I will pick up 3-4 more tasks from the backlog and complete them.

Image courtesy of Jack Moreh at
Image courtesy of Jack Moreh at

Impediments are a different kettle of fish. If a developer has an impediment then they should raise it with the Scrum Master, which can be done at any time. If a developer was to hit an impediment 5 minutes after sitting down from the standup would you expect them to wait until tomorrow’s standup to raise it? The resolution should be as simple as turning around to ask the room, speak to the scrum master or post a note to the group on Hangouts.

Impediments can and should be sorted out using the instant communication and collaboration that Agile development prescribes.

Sprint Planning and Daily Scrums may well work for some companies. However, for me personally their downfall is the fact that they are often over complicated and time is wasted that could be better and more efficiently used within the project. Pre-planning and monitoring fail to accommodate the uniqueness of each project and client; there is no one size fits all!

The Problem With Scrum