Many developers and teams in IT today are engaged in agile software development. Scrum is certainly one of the leading agile frameworks. It is now used by a lot of companies in the IT world, and we can find its implementations in some other branches as well.
In IT in 2017 there is hardly a developer who has not heard of Scrum. Many of them have worked in some kind of implementation of Scrum. Unfortunately, these implementations are most often not good enough and the teams don’t follow even the basic rules and therefore they don’t experience enough benefits of Scrum.
What is Scrum?
Let’s first answer what Scrum is. Is Scrum a process? Or a methodology? The definition from scrum guide says:
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
So, it’s not a process or a methodology, it’s a framework within which you can employ various processes and techniques. And like any other framework that you use in programming, Scrum will lead you and help you to reach your goal more quickly and easily. But like in programming, that doesn’t mean that success is guaranteed, it depends on how you “write your code” or how you use the advantages of the framework.
So, Scrum is about “delivering products of the highest possible value”. Many people say just “delivering value”. This is the most important thing. If you really use Scrum, you need to deliver something every iteration, something that is valuable to the user. In Scrum it is called “potentially releasable product increment”. Have you ever heard of a project where development is done for several months and nobody has seen anything of that project? In Scrum that is not possible.
Breaking down Scrum
Scrum consists of 3 roles (Product Owner, Scrum Master, Developer), 4 ceremonies (Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective) and 3 artifacts (Product Backlog, Sprint Backlog, Impediment List). It is organized in a set period of time, which we call the Sprint. Sprints should last at least one week and up to 4 weeks. The result of a sprint should be a product increment, i.e. something that potentially can be applied to the product.
Let’s see how it looks all together:
So at the top we see Stakeholders. Those are end-users, customers, developers… basically everyone who has any interest in developing the application. We see here that stakeholders are communicating with one person in this flow, and that is the Product Owner.
Product Owner (PO) is the role whose task is to gather all the interests and ideas of stakeholders, to filter, prioritize, and on the base of that create tasks called Product Backlog Items (PBI or User Stories). Product Owner puts all these tasks on one sheet called Product Backlog. On that list is actually defined what will be done in the product and in what order.
Next on the graph we see the Development Team. Development Team is described as “self-organized and cross-functional”. Cross-functional meaning that the team consists of professionals involved to convert an PBI into a functionality: developers, designers, QAs, SEO people … No one can tell the Dev Team how to do their job, the Dev Team is its own boss and makes independent decisions.
How does a Dev Team transform a PBI into a functionality? It all starts with a Planning Meeting that is timeboxed to 4h for a 2 week sprint (duration of the meeting is proportional to the sprint length).This meeting begins a sprint. In the first part of the meeting the dev team goes through the product backlog and decides what it is going to do in the sprint. In the second part the dev team negotiates how the PBIs are going to be turned into product increment.
After planning, the Dev team moves the tasks they decided to do from Product Backlog to Sprint Backlog. This is a board where Dev Team organizes the work. Also this board is transparent and it gives information about which PBIs are finished, which are in progress, which have not yet been started… The most common columns in the list are “ Todo — In Progress — Done .”
Dev Team starts with the development work… During the development the Dev Team meets daily at a meeting that does not exceed the 15min time limit. This meeting is called the Daily Scrum. It mostly serves to synchronize the dev team, the emphasis is on transparency and inspection of the problems. The following three questions are answered:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediments that prevent me or the Development Team from meeting the Sprint Goal?
When the time for development in the sprint runs out, what follows is a Sprint Review, popularly called a Demo. This is a meeting in which the Development Team presents to the Product Owner what was done. Product Owner decides what tasks to accept and a product increment is created. This meeting is limited to 2h in a two-week sprint. Note that here you only talk about the product, not the process of work and the problems that arise.
After that, the Scrum team needs to consider how it can improve its work. That’s what Retrospective serves for. In a Retrospective the topics are process of work, what is good, what is bad, what could have been done better…The impediments are presented and adaptation measures are set that should be implemented in the new Sprint, and that should lead to achieving more value. It is limited to 2 hours. With this meeting the Sprint ends. Retrospective is also good for the team spirit, which you can organize outdoors, in pubs, etc…
And where do Scrum Masters fit in? Everywhere. It is an essential role in Scrum. They are the ones who makes sure that this entire process takes place and that all the roles do their job properly. They have no authority over the product itself, Product Owner is responsible for it. They are responsible for the process. They take note of the impediments in work during the sprint and ensure that all these problems are transparent to the team and that the team is making effort to remove them. They use the Impediment List for this purpose. This role determines how good the application of Scrum will be.
This is a brief description of the Scrum flow and the basic elements of Scrum. More details on the roles, ceremonies and other elements you will find in the Scrum Guide. It contains all the information you need to know about Scrum.
Just remember, Scrum is easy to understand but quite difficult to implement.