[toc]
What Is Agile Scrum?
In Scrum, time is divided into work periods between one and four weeks long. These are called sprints (or iterations). At the end of each sprint, an improvement of the product is demoed and ideally delivered to the customer. Historically used for product development, Scrum has become more common for teams of all kinds.
Scrum is fundamentally different from traditional project management. There are no projects with finite start and finish dates. There also isn’t a single project manager dictating what gets done, when, and by whom exactly. Rather, in Scrum, teams deliver improvements to a product over time. Much of the decision-making power is redistributed toward the team.
Finally, there’s far less upfront planning. Scrum lets teams adjust and pivot to reactions from customers and market changes in the pace set by the sprints.
The 6 Principles of Scrum Methodology
- Control the process — Make decisions based on the information collected every day, and in every sprint. Keep artifacts and tools like burndown charts transparent. Inspect all deliverables and feedback. And adapt based on market demands, as well as what works — and what doesn't work — for the team.
- Self-organize — Teams that buy-in to their own work and process get more done and are happier. Let them self-organize and take more responsibility for who does what and how problems are solved!
- Deliver Value — Teams focus on delivering maximum value to customers.
- Collaborate — Teams should be cross-functional (as in that they do not need external help to deliver value) and work together to define and solve problems.
- Timebox — Put constraints on time to deliver an increment that you can learn from.
- Iterate — Ship. Get feedback. Ship. Get feedback. Ship. Get feedback.
Why Scrum?
Happier and better performing teams. Scrum teams have more of a stake in managing their work. Charged with their own success, they’re empowered, naturally, to do their best.
Less risk. Traditional project management involves hefty planning at the beginning of a project, which is the time when you know the least about what you’re building. Planning during this stage, then, is risky. Scrum includes much more feedback from customers at earlier stages of development. As a result, it mitigates the potential of poor product-market fit and the potentially disruptive effects of technological change.
Better products. By shipping frequently, scrum shortens feedback loops from customers. So you can continue to improve your product based on real-time results.
Scrum For Beginners: The 3-4-5 Approach
Scrum can be simply defined as a set of three roles, four artifacts, and five events. Can there be more? Yes. Less? Depends. These core elements combine to provide the structure and feedback necessary to deal with unpredictability — both inside and outside of the team — and start delivering continuous value.
3 Roles of Scrum
Scrum has two specific roles to this framework: product owner and Scrum Master. Everyone (including these two) is part of the overall team.
Product Owner — The product owner is a proxy to the customer for the team, and is responsible for conveying the vision for the product to the team and the stakeholders. The product owner is responsible for prioritizing the product backlog (a Scrum artifact), preparing the acceptance criteria, and approving items at the sprint review. A good product owner has a solid understanding of users, the market, competition, and of future trends affecting the product being developed. Importantly, the product owner dares to say no to things that don’t align with their vision.
Scrum Master — The Scrum Master serves as the team's coach, helping team members work together effectively. A good Scrum Master views the role as a servant-leader to the team, removing impediments to progress, facilitating meetings and discussions, and ensuring the agreed-upon process is being followed. The Scrum Master ensures that value is delivered as smoothly and seamlessly as possible. In reality, this means the Scrum Master must often protect the team from outsiders who may negatively disturb, influence, or control how the team is working.
Scrum Team — The Scrum development team is responsible for self-organizing to commit and complete work. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, and testers. During each sprint, the team is responsible for determining how it will accomplish the work they’ve selected from the product backlog. The team has autonomy and responsibility to meet the goals of the sprint. A typical team size is five to nine members; the Scrum Master is a part of this team.
4 Scrum Artifacts
Scrum has four clearly defined artifacts. Together, they help define the work, where it goes, and who on the team handles it when.
Product Backlog — The product backlog is a prioritized list of deliverables (such as new features) that should be implemented as part of a project or product development. It's a decision-making artifact that helps you estimate, refine, and prioritize everything you might sometime in the future want to complete. It helps ensure the team is working on the most important and valuable features, fixing the most critical bugs, or doing other important work critical to product development.
Product Backlog Item — The product backlog is made up of product backlog items (PBIs). There can be many types of backlog items, for software teams there are often four types. Two are highly visible to customers — features and bugs. The two others, reducing technical debt and spikes (research where the delivery is knowledge and not code), are invisible to customers yet can't be ignored. In an Agile organization, PBIs are typically written as user stories — though they don’t always need to be. A user story has the format "As a <user persona> I want to <useful action> so that <business value>."
Sprint Backlog — The sprint backlog is a container for work the team is committed to doing, either right now as a part of the sprint (typically a one- to four-week period). It is an output of a sprint planning meeting attended by the team. The sprint backlog, ideally, doesn’t change at all for the duration of the sprint. It consists of user stories that the team has committed to delivering within the next sprint’s timeframe. But it can also include bugs, refactoring work, and so forth. It is usually more granular, and broken down into tasks, focusing on the technical implementation of a user story. It is the purview of the scrum master and team.
Increment — The increment is the sum of all the product backlog items completed during a sprint. It is a step toward the product owner’s vision. At the end of a sprint, the new increment must be "Done," which means it must be usable, and meet the scrum team’s definition of "Done". An increment is a body of completed work that can be reviewed at the end of the Sprint.
5 Scrum Events Defined
Scrum has several defined events. These events combine to help the team focus on delivering great software filled with value.
Sprint Planning — The sprint planning meeting is held at beginning of the sprint, during which the team, Scrum Master and product owner plan work for the upcoming sprint. The meeting typically starts with the product owner presenting the current top priority items in the product backlog. At the end of this meeting, the team should have committed to a sprint backlog that they are confident that they can complete by the end of the sprint (the latest).
The Scrum Sprint — The sprint is the time-fixed period (one to four weeks) where the Scrum teams turn tasks into working software.
Daily Standup — At this short daily meeting (yes, you must stand up!), the team members primarily share if anything is blocking anyone (and who can help out) but also share the progress since yesterday and what they will do during the day.
Sprint Review* — At this meeting, which occurs at the very end of the sprint, the Scrum team presents the results of the sprint to the stakeholders. Ideally, this comes in the form of a tangible demo of the actual working product. The team showcases what exactly has been improved, and demonstrate that the acceptance criteria have been reached.
*Preferably, attendees can hold an alcoholic (or non-alcoholic) beverage to cheer on the team members in celebration!
Sprint Retrospective — At this meeting, held once per sprint, the scrum team & master evaluate:
- How the previous sprint went.
- If they did the right things.
- What can be improved in the next sprint.
At the sprint retrospective, the team focuses on the things they can improve as a team. Anything and everything that goes beyond the team’s control is delegated to the scrum master to handle.
Using a Scrum Tool
Scrum brings many benefits to development teams. It simplifies the planning processes. It optimizes development for change and team empowerment. Organizations embracing Scrum have seen radical results — it is a proven way to multiply (10x!) the efficiency of teams stuck using outdated and document-driven approaches to development.
Power Scrum With Helix Plan (Formerly Hansoft)
Power your Agile development with an Agile project management tool that helps Scrum teams visualize progress, collaborate across time and space, and ship better products. Designed for the enterprise — free for 5 users.