1.0 What is Scrum
Building software applications can be a difficult task. Scrum methodology comes as a solution for executing such a complicated task. It helps the development team to focus on all aspects of the product, such as quality, performance, usability and so on.
Scrum is a very popular agile framework for managing software development projects. It is an adaptive, iterative, fast, flexible, and effective framework designed to deliver prioritized and quick value to the customer. The customer is in the centre all the time to reduce waist. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress.
Cross-functional, self-organized, and empowered teams are the key stones in scrum, and they deliver shippable product increments in short concentrated cycles called Sprints. The Figure shows an overview of the scrum flow.
Before a development team can start the work there must be input from the stakeholder about what kind of a software product they need. In a traditional project, the work begins with some project business cases and product vision statements. Next, the product owner develops a prioritized product backlog, which contains a prioritized list of business and project requirements. Normally, this is written in the form of user stories (we will come back to that in a later chapter – just look at it as product requirements, something that a customer/user needs to give them value).
The product backlog is a long list of all requirements the product owner can think of, so that the requirements are ordered according to the importance starting from the top of the list.
In a sprint planning meeting, the development team (scrum master + the development team members) meets with the product owner and the development team then picks user stories from the backlog to insert into their sprint backlog. The sprint backlog is a list of requirements that the team commits to develop within the upcoming sprint.
During the second half of the sprint planning meeting, the user stories are split into tasks. Tasks are small pieces of work that needs to get done, whether it`s to do with development, testing, documentation, architecture, etc. The backlog items and tasks are then displayed on a sprint task board, virtual or physical. Here`s one possible layout of a sprint task board:
Now, the sprint can begin.
A sprint is the iteration period while the team builds the software product; normally, it is 2-4 weeks. In this period of time, the team code, test, document, and make a shippable product increment 100% ready. Every day, the team holds a daily scrum meeting. In the meeting, tasks are moved on the sprint board, team members share what they did yesterday, what they will work on during the day, and if something is slowing them down or blocking them to do their tasks.
After the sprint there will be a sprint review during which the team goes through each deliverable in form of a demo of the working software, and the product owner will check if all DoD (definition of done) criteria are fulfilled. The development team will also hold a retrospective meeting where they go through the just finished sprint – what went well, what did not go so well, and improvement suggestions for the next sprint are made. This will secure that the team keep doing what has shown to be successful, and they will improve continually in areas where they have not been as effective.
We will go deeper into most of this in the following chapters. Scrum is a quite simple framework, but still so many teams have problems following the simple rules. Try not to think that your team is different from other teams or companies – to succeed you have to follow the rules.