Agile Scrum
In our previous blog, we talked about Agile. A popular way of implementing Agile is Scrum. Scrum revolves around iterative improvement, reducing time waste, self-organising, multifunctional teams and visualising the workflow.
Within Scrum, you basically have 3 roles:
- Product Owner
- Scrum Master
- Development Team
Let’s think about the car example in our last blog: a client needs a fast, comfortable way to move from A to B. The scrum team will work a bit like this.
The product owner is the voice of the customer. They will listen and try to understand the needs of the customer. So where a client will probably first go: “I need a car!” It’s the product owner’s responsibility to discover the underlying problem (“I need a fast way to move around in the city). Then the product owner has to prioritize what the development team should work on next.
Important terms here are the product backlog and user stories. The product backlog is a long list of items (mostly features) that can improve the product. For a bike, this could be ‘add a front light’, ‘improve the brakes’, ‘add an electrical motor, etc. These items are often written in the form of user stories. A user story defines a piece of work that needs to be done from the perspective of the user. It is always structured like this: As a user, I want to have an electrical motor so that I can go faster from A to B.
The development team are the manufacturers of the transportation method (the car or bikes). They are self-organising and it’s their goal to make sure the car or the bikes look beautiful, that they are built from solid materials and that they are safe.
The last role is the one of scrum master. The scrum master makes sure that the development team can work as effectively and efficiently as possible. They have to identify possible blocking points (for example, when a material is missing to build the wheels of the car) and make sure that there are not too many outside distractions (for example, when a client keeps asking for new features).
So how does that work in practice?
In scrum, you work with sprints. This is a time period (often a week, 2 weeks or a month) in which the development team should deliver something (a feature for example). Take the car example. At one point we could have a bike that is working well for the customer. However, the product owner has noticed that the customer often rides at night, and needs a light. The product owner will prioritise building a light on the bike.
He will probably write a user story like this “As a user, I want to have a light on my bike, so that other people in traffic notice me”. This user story goes along with some acceptance criteria that define when the user story can be considered ‘done’. For example, for the lights it could be ‘the front light should be yellow, the back light should be red. The battery should last at least 30 hours. In the dark, you should see the light from a distance of 100 meters.”
So when a new sprint is coming up, the scrum master organizes a sprint planning. During this sprint planning, the development team and the product owner agree on the scope of the next sprint. The development team sets how much work can be delivered during the sprint (“We can deliver only the front light”). The product owner sets which criteria that works needs to fulfill (“the front light should be yellow and last 30 hours”).
When the sprint planning has been agreed on, the development team starts building the front light. During the sprint, the scrum master organizes short (max 15 minutes) daily stand-up meetings where the development teams discusses:
- What did I do yesterday?
- What will I do today?
- Are there any impediments in my way?
The goal is to discuss the progress and make sure that there are no blocking points for the development team.
The sprint ends with a sprint review and a sprint retrospective. The sprint retrospective is attended by the scrum master and the development team. The goal is to improve the functioning of the team in the next sprints. The team and the scrum master will basically answer 3 questions:
- What went well during the last sprint?
- What could be improved?
- Which points will we improve for next sprint?
The sprint review, on the other hand, is to show the delivered work to the stakeholders. So during the sprint review, the development team will show the front light that they created to the product owner and other stakeholders (such as managers or even the customer). Durint the sprint review, it is discussed whether the front light has reached the criteria that were put by the product owner.
As you can see, there is iterative development. So the goal of scrum is to continuously deliver small pieces of a product that is then improved based on the feedback from users and the teams.
This blogpost is part of Texidi’s mission to make tech understandable for non-tech profiles. Check out other blogposts explaining tech terms in an easy and fun way.
Follow us on LinkedIn and Instagram to be the first to receive the latest news about our new podcast Recs & Devs, our blogposts and much more!
Check our website to learn more about Texidi.
