How does Agile Scrum work?
The best way to find out how Scrum works is to read the Scrum Guide. But I will explain the basics in this summary.
Scrum is a framework for teams to develop software. This framework consists of three parts:
* Scrum roles
* Scrum events
* Scrum artifacts
Scrum roles
In Scrum only three roles exist:
* Product Owner (PO)
* Developer
* Scrum Master
Product Owner
The Product Owner is a single person who decides what will be delivered. In general you can say that the PO is responsible for the Product.
The Development Team, is responsible for how the product will be delivered. Within a Development Team everybody is equal. This means within the team you don’t have roles like: tester, programmer, designer and architect. Everybody has the role of Developer. This includes people who perform operations tasks, which may be a bit confusing at first. Having the same role does not necessarily mean that everybody has the same capabilities. But it does mean that everybody in the team can do all types of tasks. So programmers should also do testing and vice-versa. The reason for this is that you always want to pick up the most important tasks first, and not just the tasks that fit your specific role description. Moreover, the whole team is always accountable for all the results.
The Scrum Master makes sure everybody understands and adheres to the Scrum way of working. It is definitely not somebody who acts as a project leader and steers the team. The team must be self-steering. The Scrum Master will only coach and facilitate.
The Product Owner, the Developers and the Scrum Master together form the Scrum Team.
Scrum events
To organize the work as efficiently as possible, Scrum has defined Scrum events. These events should make all other meetings obsolete. It helps the team to focus on delivering working software with the most business value.
The events are:
* Planning the work for the upcoming period (sprint): Sprint Planning
* Building working software: The sprint
* Inspecting the work and progress by the team: Daily stand-up
* Presenting the results of the sprint to the stakeholders: Sprint review
* Evaluating how the team performed during the last sprint: Sprint retrospective
And not officially a sprint event, but usually present:
* Defining the work to be done for the upcoming period: Sprint refinement (formally known as grooming)
The Sprint.
The Sprint is a fixed period of 2-3 weeks within which the team will produce working software. The sprint duration is always the same. If the work is not done, the sprint still ends, and a new sprint is defined. The reason for this is that delivering software should be predictable. You always know when working software will be delivered. Also you want to get feedback from your stakeholders at regular times. This feedback is given during the Sprint Review. The Scrum team presents the results of the last sprint, possibly by giving a working demo of the software. The Stakeholders can give their opinions, and state what they think is important for the next sprints. In the end the Product Owner decides on this!
Every day the Development Team comes together to discuss the progress and to align. This is called the Daily Stand-up. It should take only 15 minutes and in-depth discussions should be avoided.
Scrum is all about learning and improving. So it is very important to evaluate the way of working after every sprint. This is called the Sprint retrospective. Focus of this event should be how the team can improve.
Scrum artifacts
The Product Owner keeps track all all the work that needs to be done for the Product, by putting it on an order list; the Product Backlog. This includes new features, but also fixes that come from Problem Management. The Product Backlog constantly changes. It is up to the PO to make sure the most important items are always on top of the list. Also note that only the top items are detailed out. We don't waste time on defining specifications that we don’t need now. The specs should be just enough to place them in the correct place on the Product Backlog.
When a new sprint is defined, a set of Product Backlog items is selected to implement. This list, together with a plan to realize these items, is called the Sprint Backlog. The Sprint Backlog defines how the next Increment of the Product will look like. The Sprint Backlog is owned by the Development Team.
Every sprint the team delivers an Increment of the Product. What that Increment will be is defined in the Sprint Goal, and detailed out in the Sprint Backlog. But how do you know when this Increment is done? For this the Definition of Done is defined by the team so everybody has the same understanding of done.
Scrum is empirical. This means that everything that is not defined in the Scrum Framework must be customized to your personal needs. The only way to find out how is to experiment.
How much work can a team handle in one sprint? What is the optimal sprint duration? How many people should be in the Scrum team? Try it! Fail, adapt, improve. Again and again and again.