Scrum: It’s a framework, not a project management methodology
What is the Scrum framework and how Scrum teams should use it? There are common misconceptions about Scrum being another project management methodologies.
By now most people should already know that Scrum is just a framework. Scrum just gives you the rules of the game. Scrum never tells you how to play the game but Scrum expects you to follow the rule of the game. If you are not following these rules, you can’t be called that you are using Scrum. Just like the game of soccer, it never tells you the team formation that you have to use, but to win the game you need to score the goal most. If you are not following the rules in soccer, you might be playing some other game or sport, but it is not soccer. As simple as that.
Now, this is hard to digest for some people who are used to being prescribed by a certain method or rule. So please let us tell you what Scrum expects you to do or in other words the rules of the game.
The roles inside Scrum Team
- Scrum expects sole Product Owner, who takes ownership of the Product and accountable for the Product. He is responsible for the Product Backlog and orders it from time to time. Without a Product Owner, there is no Product Backlog. Without Product Backlog, there is simply no product. As simple as that.
- Scrum expects a development team with a minimum member of 3 who will be turning the Product Backlog into a usable product. If the number of a development team members is less than 3, you do not need Scrum.
- Scrum expects someone who will act as a coach for the Product Owner and the development team. He removes impediments that is blocking the team to deliver the product at the end of the Sprint. His name is the Scrum Master. Today BVOP Certified Scrum Masters are more demanded by many organizations. He doesn’t have to be a dedicated person and can be from the development team, but Scrum expects this role exists.
- Scrum expects a sustainable and constant iteration less than equal to 1 month, which is called Sprint. If the Sprint is more than 1 month, it will be hard to manage and the result and the process are less visible for everyone. The team is expected to deliver a complete functionality at the end of the Sprint, not just a mockup, documentation, a test result or architecture, so that the Product Owner can make a decision where the Product should go next or even to deploy it to production right at that moment.
- At the beginning of the Sprint, Scrum expects the Scrum team to make a plan in a ceremony called Sprint Planning. It is quite logical that without a plan, it is hard to see where the product is heading to and what the development team should be working on. Without a plan, you are planning to fail. As simple as that.
- The scrum team is expected to make daily planning and see how far they are from completion in a ceremony called Daily Scrum Meeting. Without this ceremony, the things that are happening within the Sprint are less visible for the development team.
- At the end of the Sprint, Scrum expects the Scrum team to review what the development team has produced in one Sprint in a ceremony called Sprint review. Because software is abstract, by having a review we are ensuring that we are building the product that the Product Owner requested.
- After the Sprint Review, the Scrum team is expected to inspect the process in one Sprint and make it better for the next Sprint. Everyone wants to become better and so does Scrum team hence the Retrospective.
The Scrum artefacts
- Scrum expects an ordered Product Backlog, a list of things that makes the Product comes to existence.
- Scrum expects a Sprint Backlog, a list of things that the development team should do in one Sprint. Sprint Backlog must fit in one Sprint hence you may need to decompose it so that it fits in one Sprint. If it is not decomposed well enough to fit in one Sprint, it will be less visible to track what is actually being done.
Now that we have told you the framework, by now you should know that everything else outside the framework is either best practices or preferences. Best practices maybe someone’s personal opinion and is not part of Scrum hence you don’t have to use it if it doesn’t make sense to you. Preferences are things that Scrum has found out through empirical process about what makes Scrum process more optimal but it doesn’t mean you have to use it if it doesn’t fit in your business context.
Best practices for Scrum Teams, Product Owner and Scrum Master
- Scrum never expects Product Backlog must be written in a User Story. Even though User Story is nice, you can use other formats that make sense or even create your own standardized format that is used company-wide.
- Because Scrum never expects you to write Product Backlog in User Story, Scrum never expects you to estimate in story points either. You can even estimate in hours if it makes more sense to you. Both User Story and Story points are best practices that were adopted from eXtreme Programming and was not part of Scrum.
- Scrum never expects you to have a co-located team but Scrum prefers to have a co-located team so that the team may have a high-bandwidth communication.
- Scrum expects you to have an accountable Product Owner but Scrum never expects you to have the Product Owner on-site. Having a Product Owner on-site is a preference to prevent miscommunication with the Product Owner and to speed up the communication line whenever the development team needs clarifications from the Product Owner.
- Do not forget to check the best Product Owner certification courses and training.
Once you know the expectations and preferences, you will understand that Scrum never wants to make your life more difficult. Most of the framework is actually common sense. We hope this article is clear enough so that everyone can see where they can use Scrum in their organization.
More Agile Resources and events
The Agile 2020 Conference sessions are distributed into Tracks to help you find sessions about particular topics. Check on the tracklist. Then go to the…
In our experience helping companies implement Scrum, Product Ownership recurs over and over again as THE big issue. In this blog article, we provide some guidance on what makes a good product owner and include a…
Scrum is not that easy and different issues may arise. A recurring question I am often asked is “how do I deal with…