The Agile-scrum methodology is an iterative and incremental agile software development framework for managing product development. It’s one of the leading agile development methodology – a feedback-driven empirical approach which is, like all empirical process control, is used for complex work where more is unknown than is known and predictions have little value given a high rate of change and uncertainty. The Agile-scrum methodology processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals.
Agile vs Scrum: Agile methodology is a group of different software development methodologies based on iterative and incremental approach. All agile methods, including Scrum, emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond quickly to change. The Agile-scrum methodology is just one of the most popular frameworks for implementing agile. So popular, in fact, that many people think scrum and agile are the same thing. They’re not!
With Agile-scrum methodology, the product is built in a series of fixed-length iterations called sprints that give teams a framework for shipping software on a regular cadence. Milestones–i.e., the end of a sprint–come frequently, bringing with them a feeling of tangible progress with each cycle that focuses and energizes everyone. A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Events (ceremonies) and Artifacts.
The Agile Scrum Project: Main Roles
There are three core roles in the Agile-scrum methodology
Champion for Business! Product owners represent the customer’s interests and are focused on understanding business and market requirements. Product Owners bridge the communication gap between the team and its stakeholders – writes customer-centric items (typically user stories), prioritizes them based on importance and dependencies, adds them to the Product Backlog, demonstrates the solution to key stakeholders, defines and announces releases, communicates team status, organizes milestone reviews, educates stakeholders in the development process, negotiates priorities, scope, funding, and schedule and ensures that the Product Backlog is visible, transparent, and clear. Keep in mind that a product owner is not a project manager.
Champions for sustainable development practices! The Scrum Team is responsible for delivering potentially shippable increments of product at the end of each Sprint. The team does the actual work (analyse, design, develop, test, technical communication, document, etc.). For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. The team has autonomy and responsibility to meet the goals of the sprint.
Champion for Scrum! They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. The Scrum Master acts as a facilitator for the Product Owner and the team, who is accountable for removing impediments to the ability of the team to deliver the sprint goals and deliverables. The Scrum Master is not a traditional team lead or project manager. The Scrum Master ensures that the Scrum framework is followed. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.
One way to think of the interlocking nature of these three roles in this agile methodology is as a race car. The Scrum team is the car itself, ready to speed along in whatever direction it is pointed. The product owner is the driver, making sure that the car is always going in the right direction. And the Scrum Master is the chief mechanic, keeping the car well-tuned and performing at its best.
The Scrum Events: Ceremonies
Sprint (or iteration) is the heart of Scrum. The Sprint is a time-boxed effort; that is, it is restricted to a specific duration and is normally between one week and one month, with two weeks being the most common. A shippable product Increment is released at the end of each sprint. Scrum calls for below ceremonies that bring structure to each sprint:
Held at the start of each sprint to define the Sprint Backlog (importing stories from the Product/Release backlog), i.e. items that can be completed in the current sprint. As you might have guessed, the Product Owner drives Sprint Planning as in which stories are highest in priority.
Presided over by the Scrum Master, Daily Scrum is a 15-minute stand-up meeting to synchronize the work of team members, i.e. what’s done on the prior day, what needs to be done today, and identify any impediments. It is also a means to track Sprint progress.
Held at the end of each sprint to demonstrate the added functionality. The goal is to get feedback from the product owner and other stakeholders to ensure that the delivered increment met the business need and to revise the Product Backlog based on the feedback.
Held at the end of each sprint to reflect on the completed sprint and identify opportunities to improve in the next – what went well, what did not and what can be improved. It allows the team to focus on its overall performance and identify strategies for continuous improvement.
The Agile Scrum process: Artifacts
The primary artifact in Agile-scrum methodology is, of course, the product itself. The product increment is the sum of all the Product Backlog Items completed during a Sprint and all previous Sprints. At the end of a Sprint, the increment must be complete and in a usable condition regardless of whether the Product Owner decides to actually release it. The Agile-scrum methodology Project Management requires very few artifacts, concentrating instead on delivering software that produces business value. The main artifacts in Scrum are:
An ordered & complete list of system, project or product requirements. It consists of features, bug fixes, non-functional requirements, etc.—whatever must be done to successfully deliver a viable product. Product Backlog Items are articulated in any way that is clear and sustainable. The Product Owner orders the Product Backlog Items (PBIs) based on considerations such as risk, business value, dependencies, and date needed so that the team always works on the most valuable features first.
Created during the Sprint Planning, it is a list of work to be addressed in the current Sprint, i.e. top-most items from the Product Backlog that can be accommodated in the next sprint. The sprint backlog can be thought of as the team’s to-do list for the sprint. Once a Sprint Backlog is committed, no additional work can be added to the Sprint Backlog except by the team.
Sprint Burndown chart
The remaining effort required to complete the sprint tasks – an effective way to determine at a glance whether a sprint is on schedule to have all planned work finished. Additionally a way to determine how to overcome obstacles and meet commitments.
Once a Sprint has been delivered, the Product Backlog is analyzed and re-prioritized if necessary, and the next set of functionality is selected for the next Sprint.
The Agile-scrum methodology is a lightweight methodology, which is simple to understand yet difficult to master. Scrum’s early advocates were inspired by empirical inspect and adapt feedback loops to cope with complexity and risk. Ever since its first publication in 1995 up to now, Scrum has been adopted by a vast amount of software development companies around the world. Scrum offers multiple benefits like reduced time-to-market, improved stakeholder satisfaction, better team dynamics, higher productivity and better-quality products. It is today recognized as the most applied framework for agile software development. More than 1000 books have been published on Scrum. The method however has also been successfully applied in other domains, e.g. manufacturing, marketing, operations and education.
Why Is It Called Scrum?
When Ken and Jeff created the scrum process in 1993, they inherited the name ‘Scrum’ from the 1986 groundbreaking paper ‘The New Product Development Game’ by Takeuchi and Nonaka, two acknowledged management thinkers. With the term ‘Scrum’ Nonaka and Takeuchi referred to the game of rugby to stress the importance of teams in the game of new product development – comparing high-performing, cross-functional teams to the scrum formation used by Rugby teams. They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth”. In rugby football, a scrum refers to a tight-packed formation of players with their heads down who attempt to gain possession of the ball. Teams require autonomy to achieve excellence.
Do you have any tips or experiences to share for Agile-scrum methodology? Do leave a comment below!