ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel
  • »
  • Business and Employment»
  • Business Management & Leadership

The biggest myth about scrum project management

Updated on August 19, 2013

The growth in scrum project management

Look on the website of any software development company nowadays, and you'll probably see claims of agile development methods. You may even see the term scrum mentioned.

Scrum is the popular choice of late. It has become fashionable due to a modern and simple methodology, promoted heavily by training companies who can offer certification in this technique. It has received great feedback from technology companies and from developers in particular, who embrace the methodology for its skill in making all team members feel involved in the project. It is less dictatorial.

Yet one myth continues to persist. Many companies, and managers in particular, are drawn to scrum as a way of speeding up projects through rapid development. The perception of scrum is that it requires less planning, fewer documents, and will result in a quicker project.

Wrong. I'll explain why.

Planning is central to scrum project management

Planning is actually a core component of scrum. The reason it doesn't get the same bad press that planning does with traditional project methodologies is because it is spread more evenly across the project rather than assigned its own phase at the start. Its only when assigning 'planning' to an entire phase does it become high profile and risk the scrutiny of the senior management team who wonder why you aren't 'getting on' with the tasks in hand.

Planning time compared to traditional project management methodologies

I looked at 50 past projects I managed and did a data comparison between how much planning time was spent on Scrum projects compared to more traditional methods (in this case, PRINCE2). The result? Of all the time booked on the project, 25% of that could be attributed to planning on a PRINCE2 project, and this rose to 30% on scrum.

So what planning happens on a scrum project?

So let's look at the evidence. What planning activities happen on a scrum project?

1) The product backlog

The product owner creates the list of features that will go into a product. This is called a product backlog. This in itself could be considered a planning activity and may take the form of a collaborative meeting with the relevant people. Whilst it may not seem like planning on the surface, think back to how you write a project plan. Some of the effort involved in writing a project plan is to think about what is to be delivered. This is a similar activity. A product backlog looks at what features the product needs to have, before even a line of code is written. There is definite planning involved in this approach.

2) Sprint planning

This is the critical area of scrum where planning really comes into its own. If you assume a typical project with sprints that run every two weeks, sprint planning will take a full day of that. This is a significant amount of time on a project. Multiple meetings are spent simply looking at planning. Compare this to traditional project management where planning might take the form of a single meeting at the start of the project, and may be discussed for 10 minutes during a regular progress meeting.

3) The sprint backlog

Consider if you will the scenario where you monitor progress against your project plan. This isn't just a control activity, but it is also a planning activity. After all, if something is off schedule then you need to start making adjustments (or re-planning). The sprint backlog is a vital monitoring activity for the project; a way of measuring progress of the sprint and ensuring you are on target to meet your goal. If you are behind, things need adjusting, and again you are into a planning activity.

The perception of planning

As I mentioned earlier in this article, on more traditional methods of project management planning is a highly visible activity. It has a start date and a finish date and more often than not it even has its own phase in the project. Senior managers will know this activity is going on.

The problem comes when you are dealing with a client or a project sponsor who isn't keen on planning. Planning has become a negative word in the more fast paced competitive businesses of today's world. It is seen as too much talking and not enough doing. That is why managers are likely to favor a method which appears to show more of the 'doing' activities. Scrum does this. By early activity and early output, it appears to an outsider that scrum methodology shuns the task of planning.

This of course, is not true, as I have demonstrated. What scrum does very effectively is make planning an integral part of the overall project, to be carried out repeatedly, and collaboratively. This lessens the perception that work is on hold.

What can we learn from this?

There are a couple of points that can be taken away from this. Firstly, planning can be a bit of a political hot potato in many organisations, who want to see action on a project and may perceive planning to be non-productive activity. You can steer around this problem as a project manager by using the lessons of scrum. Make planning such a core part of your project that it becomes seamless with the rest of the activity.

The second lesson we can learn from this is that many organisations and individuals believe in the myth that scrum is anti-planning. Of course, this just isn't true. It is the opposite. It is pro-planning. It demonstrates that despite the benefits of scrum, many are choosing it for the wrong reasons. Planning is about getting things done right, not slowing things down. The reason scrum is so effective is because of the emphasis it places on planning, and the benefit this has on delivering not a quicker project but a higher quality project at the end of it.

Further reading - recommendations

Agile Project Management with Scrum (Developer Best Practices)
Agile Project Management with Scrum (Developer Best Practices)

A thorough book on Scrum, written by Ken Schwaber, one of the original architects of scrum


Planning time in organisations

Does your organisation actively seek to reduce planning time on a project?

See results


    0 of 8192 characters used
    Post Comment

    • LLambie profile image

      Lauren 4 years ago from UK

      Thank you! I think I might need to revisit how I presented that data because I don't think it was bad that the figures were higher on scrum. The projects were more successful. I might need to add that.

      I agree with you that traditional planning methods are better suited to some projects. Before I got into writing I project-managed hosting environments and they were certainly better suited to traditional methods because once you'd bought and installed the kit its difficult to start changing things/re-planning etc. Good point!

    • PegCole17 profile image

      Peg Cole 4 years ago from Dallas, Texas

      Interesting observation about the timing required in both methods of project management planning. In software projects, many of the requirements change along the way and flexibility is the key. I find it interesting that your data comparison showed scrum to be less effective than traditional planning methods. Most of my projects involved hardware delivery, installation, testing and then software application and more testing before cutover, so planning was essential upfront.