What is Scrum?

If anyone thinks Scrum is now known to everyone involved in software development or project management, think again.  ‘What is Scrum’ is still one of the most searched terms on the web (in relation to agile development that is).

According to the Scrum Alliance, “Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.”

For me, that still doesn’t describe what Scrum is.  “An agile framework for completing complex projects” – that could be anything!

Here is my attempt to define it more clearly:

Scrum is a simple and repeatable way of managing work.  It can be used for projects, or for ongoing activities.  It was originally designed for software development work, although is not specific to software development so can be used to manage any work.  

Scrum  is based on the principles and values of the agile manifesto, which proposes a different style for managing software development work, encouraging an emphasis on people over processes, working software over documentation, collaboration over contract negotiation, and responding to change over following a plan.

The term agile has also become synonymous with an incremental and iterative approach to software development.

Over the years, I have seen various diagrams that try to depict Scrum.  In my opinion, they are not great because they often look over complicated to me, or they leave too much to the imagination.

In an effort to address this, I have had a go at creating a clearer summary diagram for myself:

Scrummary :)

All of the activities referred to in the above diagram are covered in my series How to Implement Scrum in 10 Easy Steps.  They are also covered in my eBook – Agile Made Easy! – which covers how to implement Scrum and also 10 Key Principles of Agile.

Hope this has been helpful…


3 Responses to “What is Scrum?”

  1. Victor Hernandez says:

    Scrum – simple and elegant; the flow diagram that you put forth is straight and to the point, and I do feel that it removes any possible confusion.

    I enjoyed this, Kelly – thanks!

    Victor (@vhernandez)

  2. Hi,

    thx for good introduction on the flow.

    One small issue that is often spoken about the last months, the product backlog should not be prioritized but ordered.

    A huge difference as it is explained in this article: http://www.scrumalliance.org/articles/367-its-ordered–not-prioritized

  3. Kelly Waters says:

    Hi Kenneth. Thanks for taking the time to comment here. There’s a problem with the link btw, the correct link is here:


    I read this article and I have to say this chap is far too clever for me! The article makes something very simple seem very complicated!

    Personally I think it’s a semantic point. I agree that the backlog should be ordered, rather than putting things into groups of priority 1, 2, 3, for example. But I also think the word ‘prioritised’ can also mean to put it in priority order and that’s perfectly valid too.

    I also think that the idea of building a house roof-first because the roof is the highest priority isn’t a good example. My personal interpretation of priority would not allow that. It would be an earlier priority to build some walls to put the roof on, and an early priority to lay some foundations so the walls stay up. They are higher priorities, not because they carry more business value in themselves, but because they are important things that the roof is dependent on.

    Anyway, that’s my take. But certainly we’re agreed on one thing. The product backlog should be a list of the things you want or need to do to the product, in the order you want or need to do them.


Leave a Reply

What is 2 + 10 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)