4 MIN READ
Like agile, scrum is often defined in different ways by different people. Still, let’s drill down on the key tenets of the scrum philosophy to see how scrum is applied on a day-to-day basis.
Scrum, defined
Okay, while everyone has their own idea of the exact definition of scrum, let’s take it from the horse’s mouth, so to speak.
Scrum.org defines it as:
“A simple framework for effective team collaboration on complex projects.”
The scrum site also says that, since scrum is flexible, it’s not a methodology. They do say, however, that if you modify it in any way, it’s not scrum.
So, how can it be flexible if you can’t modify it?
Well, it’s built to be flexible, so it doesn’t need to be adapted. Classification aside, if we look at two interlapping time periods, we get a better idea of what scrum is.
Scrum is based around 2 week iterations of work, with planning, reviews and retrospectives. Within this two week cycle, there is a 24 hour cycle, with a daily scrum that brings transparency and keeps the team focused and adaptable.
With these two cycles, scrum essentially acts as a system of working that improves efficiency and team cohesion to deliver a more effective project.
The three pillars of scrum
These three pillars help give an overall context to all the other elements of scrum.
Transparency
Everybody within the team should have a clear understanding of the work that has been completed and the work that is to come. They should know exactly what is expected of them and other members of the team and they should have a clear definition of when the work is ‘done.’
Inspection
Each and every member of the scrum team, from the product owner and the scrum master to the development team, will regularly inspect artefacts. They do this to find problems and flaws within the software, ready for the adaptation period when these problems are addressed. Inspection also comes in the form of feedback from the customer/client and other stakeholders.
Adaptation
This pillar is what makes scrum a flexible framework. A transparent workflow and work that is regularly inspected opens up the opportunity to adapt, allowing for continuous improvement. By frequently gathering feedback and embracing change, the team can produce better work and improve overall ROI.
The primary components of scrum
Roles
Product owner
The person responsible for setting and defining the features of the product that are required. The product owner comes up with the ideas that are turned into products later down the line.
Scrum master
An overseer of the process, the scrum master is responsible for running the daily scrums and keeping the team happy.
Development team
A team of developers, testers, writers and any other kind of workers who help produce the product. Members of the development team can have specific roles but, more often than not, they will take on multiple roles.
Eventos
Sprints
Sprints are a short period of time in which the development team produces a specific piece of work and achieves a specific goal that’s valuable to the product owner. They typically last 1–3 weeks and are made up of four stages – plan, build, test and review.
The team collaborates to create the time period and sticks with this time period. Once the sprint has started, they don’t extend it or shorten. If work is leftover, they can transfer it to another sprint.
Daily scrum
A short time-boxed meeting for the team to coordinate their work to best achieve goals set by the sprint. Daily scrums, often called ‘daily standups’ are short, sharp and concise, getting to the point and giving each member of the team a chance to update everyone on their daily progress and goals.
These face-to-face meetings bring transparency and clarity to the team, following agile principles.
Sprint review
A collaborative meeting to showcase achievements during the sprint and get useful feedback from stakeholders. This can include a demo of the product. The review should point the team in the right direction.
Sprint retrospective
This is the team’s final reflection on what went well and what could be improved. The sprint retrospective is seen through the lens of the three pillars – transparency, inspection and adaptation.
Artefacts
Product backlog
This is a list of requirements set by the product owner. This is typically a list of features, or ‘user stories,’ that the product owner sees as key elements to producing a good ROI. This list evolves with every sprint. User stories should fulfill a need and have a reason to fulfill this need.
Sprint backlog
The sprint backlog uses the product backlog as a source to list the key requirements for the sprint, taking those user stories that are the highest priority. The backlog is set during the sprint planning stage and helps keep the team focused on specific goals, without the distractions of all the other requirements from the full product backlog. Progress is monitored through the burndown chart, which shows the completion of sprint backlog tasks. The burndown works towards ‘0’ as tasks are completed.
Increment
This is the work that is delivered by the development team. The increment should be shippable or deployable – essentially, it needs to be able to be completed, with all testing and clean up carried out.
4 MIN READ