What’s so Great About Scrum Methodology ?
Scrum methodology is part of the Agile group of methodologies that have been shaping software development since the 90s. How does it differ from other methods that are all part of the Agile paradigm?
Essentially, Scrum adheres to the idea of controlling processes within a project in an empirical way. Instead of setting schedules and forecasts based on guesswork (even if it’s the best, educated guess there is) or uniformed forecast, weekly or bi-monthly meetings occur where everyone sets milestones and determines the next phase of the project from there.
Scrum methodology calls for the project to be developed in succinct work cadences or sprints that are usually one, two or even three weeks long. Once these sprints end, the members of the team and the stakeholders meet and determine how the sprint did and what should be expected at the end of the next sprint. What this does better than the waterfall approach is that you are able to adjust the project’s direction based on the completed work and not on predictions and speculations that may not come true.
As you may have noticed, the fact that it allows projects to be developed on a cyclical basis with less emphasis on a target end date makes it popular. So if the work is never determined until it’s actually about to be done on that particular sprint, how do you keep the project on track and the team from slacking?
Scrum methodology depends on a set of rigid of simple roles and responsibilities given to each stakeholder in the project. These tasks, roles and responsibilities never change. The project may adapt but the team members always know what they’re supposed to do. For a software development method that likes to say it’s adaptive, the roles it uses sure don’t change—so how does that even make the model workable?
The danger with sprints is that the project outcomes and scheduled releases can become too unpredictable and adaptive. When this happens, a stable set of roles and practices can ground the team and get them back on track. Everyone goes to do their job even if the next phase proves to be a major difficulty.
The Scrum Cheat Sheet
When you’re training a new team to adapt Scrum project management and the Agile methodologies, it’s important that they have a quick reference guide for the terms and practices associated with the approach.
I’ve put together some important terms and concepts they should understand:
1 – Scrum Roles
Also known as the client, this person or entity is responsible for communicating the vision of the product to the development team. They usually write the first user stories or provide the requirements and prioritization. Since the product owner is the most powerful role in the whole team, they are also the one who are ultimately responsible for the success of the project. If the project turns over on its head, they’re the ones who have to take responsibility.
The Product owner also represents the stakeholders or the interests of the customer. His main responsibility is to ensure that the team delivers value to the company or organization. He or she is the primary (but not only) source of User Stories and has the power to prioritize items on the Sprint product backlog. If you’re the PO, you have to effectively communicate the stakeholders’ interests to the team.
Don’t mistake this role for the project manager. The truth is, the project manager can be a role outside of Scrum since it doesn’t adhere to the rigid tasks and responsibilities of the Scrum methodology. Essentially, this person’s allegiance is only to the team and he or she removes all the impediments in the team’s way to a successful project. Scrum masters are responsible for removing impediments to the ability of the team to deliver the product goals and deliverables. Keep in mind that they are not a project manager since their allegiance is to the team and not the stakeholders or the product owner. Here is an article about 10 Scrum Master tips .
Team member.
Clearly, these stakeholders are responsible for completing the work. Scrum methodology usually calls for 7 cross-functional members. In Scrum project management, the team members must be experts, senior developers, they should typically be made of software engineers, architects, programmers, analysts, QA experts, testers and UI designers. The team members have to be self-managing and organizing but also have great responsibility since they have to meet the goals of the sprint through their own way. These are the people responsible for executing the work and performing most of the tasks related to developing the software.
2 – Events
Sprint. The basic unit of development in Scrum project management is called Sprint. It is an iteration or a cycle that is repeated on a weekly, bi-monthly or three-week basis depending on the agreed-upon period. The typical sprint is broken down into:
- Sprint planning meeting – where the User Stories are written, prioritized and added to the Sprint product backlog. Metrics are chosen and the Product Owner gets to set expectations. The team can also decide to plan and distribute the tasks on the backlog.
- Daily scrum meeting – short daily meetings where intense discussions on the output and deliverables. Sometimes, the backlog evolves and tasks are added or moved to the next Sprint. Take note that these meetings are timeboxed to only 15 minutes to create intense discussion and a sense of urgency about the work.
- End meetings – this is where the Sprint retrospective and Sprint Review Meetings occur:
- Sprint retrospective –the team members reflect on the past sprint and make improvements to the processes and practices.
- Sprint Review Meetings – the work is reviewed and presented to the stakeholders and the product owner. This meeting is also time boxed to four hours.
3 – Artefacts
Essentially, these are the objects and materials that all Scrum project management initiatives have:
- Product backlog. This is an ordered list of requirements that is maintained for the product. Keep in mind that this isn’t your usual requirements document but an evolving board of User Stories that are broken down into tasks or other User Stories.
- User Story. The main item of the Product Backlog, it comes in the format of “As a user, I want <goal/desire> so that <benefit>.”
- Sprint backlog. This is the list of work the team must address during the next sprint. This list is developed by taking items from the product backlog and prioritizing them for that particular sprint.
- Burndown Chart. This is a great metric for determining the product of the sprint. It’s basically a coordinate axis that shows the remaining work in the sprint backlog. This chart should be updated every day and is used to evaluate the performance of the team and how the processe and practices can be improved.
Scrum methodology sounds exciting but it’s very easy to bungle—trust me, I’ve seen it happen so many times. How do you no bungle it? Take a look at my other articles on helpful tips and practices.
