As a Scrum Master I’m often asked what Scrum is and what I’m doing the whole day long. Well, part of my job is to teach new colleagues exactly that. Now we’d like to share this knowledge with you in our Scrum Basics Series. This series will consist of 6 parts and starts with the basic question: What is Scrum?
So let’s start with a short definition:
“Scrum is a team based framework to develop complex products or systems in an iterative way.“
What does that mean in detail?
In Scrum you are always working in a team. This team should be cross-functional. It should have all the abilities needed to fulfil the tasks, e.g. in software development a team consists of backend developers and frontend developers as well as designers and testers. In an ideal world it would go from creating concepts, over developing and testing the product, to rollout, marketing and sales. But most companies “only” have the development part in their Scrum teams. The members of those teams should strive to get “T-shaped”. That means they not only have one field of expertise, but also a broad basis so they can help out in other areas in the team. That doesn’t mean everyone should know everything, it only means everyone is willing to do more than just their own thing.
Advantages
The big advantage of those teams in comparison to assigning a single person to specific parts of the product development is that you always have all the abilities needed in one room. In waterfall you often have the problem that the person who did the backend development is already working on the next project when the designers realise that they need some more data from the backend. In Scrum that won’t happen. Another advantage is that you always have several eyes on one problem. Solutions can be found faster if you have more experience in the room and people who get stuck at some point always have someone to ask right next to them. And let’s not forget the much faster feedback cycle with the testers when they are right inside the team! No ticket is really done until it has been tested.
How is Scrum made for developing complex products or systems?
Complex problems are usually better solved if more minds are involved. An idea can be good but it will only become really great if you open it up to your team partners and get as much information and experience involved as possible. If you have to do the same thing every day again (like on an assembly line), Scrum would be too much overhead, you could use Kanban instead. But if you have to solve new challenges every day and are working on complex products, Scrum is your best choice.
Iterations
The iterations differ between the teams from 1 to 6 weeks. Usually they are 2 weeks long. That means you only plan in detail what will be developed for the next two weeks. You will then get feedback on the development and include this feedback into your next iteration. This way you get quick feedback and alway know if you are developing the right thing. You don’t need to be afraid of the “waterfall-projects-trap”.
All that may sound more difficult than it actually is. In contrary, the Scrum framework is so simple that it easily fits on one sheet of paper.
Two important artefacts in Scrum are the Product Backlog and the Sprint Backlog. The Product Backlog is an estimated, prioritised list of tickets (stories, bugs, tasks) that is sorted by the Product Owner according to the business value of these tickets. That means this list contains all the tickets that need to be done for a product to be developed. The Sprint Backlog is also a list of estimated, prioritised tickets, but it only contains those tickets that will be solved within the next iteration.
In the middle you can see the iteration, in Scrum called Sprint, which is a period of time (at ePages it’s 2 weeks) during which the tickets in the Sprint Backlog have to be done and the scope of the Sprint Backlog should not change. The development status of those tickets is represented on a so called Scrum Board or Sprint Board. It provides an overview of all tickets of one team for one Sprint including the status of those tickets (e.g. Open, In Progress, Review, QA, Done) and which team member is currently working on which ticket. With this Scrum Board everyone knows at all times about the development status and if the team is struggling or ahead of time. It also shows if one person is working on too many tickets at the same time or if the team has a long queue in QA or Review.
At ePages we only have one team that is using a paper board. Having a visual board present in the room at all times has more advantages for them. The quick and easy way of adding tasks to stories (more about that in Estimating) outbalance the higher administrative effort that occurs because one has to maintain the tickets on the physical board as well as in Jira. The other teams are using Jira Boards.
What will be next?
Scrum defines three roles, which are Product Owner, Scrum Master and the Development Team. Those roles will be discussed in detail in the next part of this Scrum Basics Series.
Next to the roles Scrum brings four standard meetings: Sprint Planning, Daily Standup, Sprint Review and the Retrospective. We will talk about these meetings in detail in Scrum Meetings.
Related posts
- Scrum Basics: Scrum Roles
- Scrum Basics: Scrum Meetings
- Scrum Basics: Estimating
- Scrum Basics: Principles and Values
- Scrum Basics: Practicing it
About the author
