The Beginner’s Guide to Scrum Software Development
A framework for the agile software development method, Scrum is one of the most widely used development methods around. It promotes team collaboration and allows teams like ours at EL Passion to be flexible and self-organize to get the job done efficiently.
But when you know nothing about Scrum, terminology like ‘Sprints’, ‘Scrum Masters’ and ‘Product Backlog’ can be incredibly daunting. It might even put you off using Scrum altogether.
That’s why we’ve put together ‘The Beginner’s Guide to Scrum’. More than a glossary, this article will walk you through the key components of Scrum and explain exactly how they can be effective.
Product Owner, Scrum Master and the Development Team
Scrum is nothing without its three core roles. Sectioning the team up, Scrum’s roles provide everybody with responsibilities and make sure everyone is accountable for the work that they’ve done.
The threes roles are as follows: Product Owner, Scrum Master and the development team.
Product Owner
The Product Owner is one of the busiest roles in Scrum as not only do they have to outline the product vision (i.e its purposes and aims) they also have to look out for the best interests of the customer and the stakeholder. The PO has to make sure the rest of the team caters to these needs on time and on budget.
Furthermore, the Product Owner needs to have qualities such as empathy and good communication. The PO is the bridge between the team and the customers (or clients), and so he needs to understand and respect the requests and restraints of others.
Development Team
The development team meanwhile, is the group of people who implement the product’s features. A self-organizing group, they analyze, test, develop and design the product ready for to be shipped.
Under Scrum, the development team must be prepared to let go of traditional processes. In Scrum the idea is that teams organize based on skills not on set team templates, using those abilities to help ship the product.
Scrum Master
Finally, the Scrum Master’s job is to make sure that the development team is doing as planned. They will have to remove any distractions getting in the way of development.
The Scrum Master isn’t a team leader in the traditional sense, but he must employ leadership qualities. The Scrum Master must also make sure that people are using the Scrum process as intended, making their role all the more vital to the overall success.
These roles are useful to employ because it prevents people from getting their wires crossed. If everyone knows what they’re meant to do, they won’t get confused or caught up in unnecessary tasks.
Product Backlog
Another responsibility of the Product Owner is deciding what should be on the Product Backlog. A list of features, bug fixes and other necessary requirements to make the product a success. The Product Backlog should be followed closely.
The Product Owner should decide not just what’s on there (with some input from the rest of the team) but in which order the tasks should be tackled. The items are usually ordered in terms of business value (what will benefit the company the most) but priority and the time needed to complete the item are other factors too.
The reason the Product Backlog is so important to Scrum (and to development in general) is because it allows you do deliver on time and helps make the product more valuable.
When each item has been ordered for its value (for example, the Return On Investment) you can maximize it to its full money making or user satisfying potential.
Backlog Refinement
The product backlog can further be improved by backlog refinement. This is the on-going process of making sure that priority items are listed as such and that each task’s importance is clear to the development team.
Refinement can also be used to break big tasks into smaller ones if the team feels that the tasks can be completed more efficiently by doing this.
Sprint
Those aforementioned roles are tested during Scrum’s ‘sprint’ sessions. Usually lasting for two weeks, a sprint is the period of time in which the team puts the product together.
Sprint Backlog
The sprint also uses a backlog, handily called the ‘Sprint Backlog’, which is comprised of things from the Product Backlog. In order to decide what’s on there, teams must consider how much time they have, which features will be the most tasking and how important it is to get these things done.
Sprint Burndown Charts
Sprint burndown charts should also be used when managing sprints. A public chart that’s updated daily, it prevents the team from having to jump through hoops to find out what has been done and what still needs to be completed. Instead, it tells the reader the remaining days for tasks to be completed and the progress so far.
Sprint Meetings
A successful sprint also depends upon meetings: planning meetings, daily meetings and end of sprint reviews.
The planning meeting is held at the beginning of the sprint and is used to prepare the Sprint Backlog and to estimate how long it will take for the development team to do the work.
The daily meetings meanwhile, let the team check in with one another. Here, members of the development team can figure out where everybody is with their work, what people are doing to aid the sprint and which things stop them from meeting their goals. Daily meetings are helpful in figuring out potential roadbumps.
Finally, at the end of the sprint review, the team reviews what was or wasn’t completed. Completed work is demoed and presented to the stakeholders.
Sprint Retrospective
With sprints being the units in which development work is completed, it’s important for the team to understand how the sprint process can be improved. What went wrong? What stopped the sprint from being as effective as it could have been?
These are all questions for the sprint retrospective where teams reflect on the past sprint. The sprint retrospective is facilitated by the Scrum Master and is a key piece of the puzzle as it allows your team to make better, more efficient use of the Scrum method in future.
As well as allowing you to put together an agenda for the work that needs to be done, a sprint is useful for boosting the quality of a product. Because the aim of a sprint is to make a working feature or product, no work is left unfinished having to be completed further down the line.
And that covers the Scrum process in general. This blog post should be enough if you’re starting Scrum with your team. If you want to learn more read up on our other agile software development articles.
