Scrum project management is a methodology for managing software delivery that comes under the broader umbrella of agile project management. It provides a lightweight process framework that embraces iterative and incremental practices, helping organizations deliver working software more frequently. Projects progress via a series of iterations called sprints; at the end of each sprint the team produces a potentially deliverable product increment.
The main activity in Scrum project management is the Sprint, a time boxed iteration that usually lasts between 1-4 weeks, with the most common sprint length being 2 weeks.
Scrum Project Management requires very few artifacts, concentrating instead on delivering software that produces business value. The main artifacts in Scrum are:
There are three main roles involved in Scrum project management:
In 2010, Scrum.org codified Scrum by creating and publishing the Scrum Guide for free. This roughly 15-page guide represents the official rules of Scrum and is maintained by Scrum’s creators, Ken Schwaber and Jeff Sutherland. It is available in 30 languages and downloadable at http://www.scrum.org/scrumguides.
In Scrum, the Product Backlog is the single source of requirements for any changes to be made to the software product. This list includes features to be added, as well as bugs to be fixed. It is the Product Owner’s responsibility to ensure that the Product Backlog is available, transparent, understood by the Development Team, and ordered (prioritized). The Development Team collaborates with the Product Owner, and others as needed, during Sprint Planning and Product Backlog grooming to understand and estimate the effort required to deliver the items in the Product Backlog.
The Sprint is a time-boxed event that contains the other Scrum events. Sprints should be a month or less in duration. The first event within a Sprint is the Sprint Planning meeting. In this time-boxed event, the Scrum team collaborates to plan the work of the upcoming Sprint. The Product Backlog items (PBIs), ordered at the top of the Product Backlog by the Product Owner, are discussed. The Development Team forecasts those Product Backlog items that it believes it can complete by the end of the Sprint. A Sprint Goal is crafted, and the Sprint Backlog emerges. The Sprint Backlog contains those items selected by the Development Team plus a plan for delivering them. The Sprint Backlog shows the work remaining in the Sprint at all times.
The bulk of the Sprint’s time-box will be spent developing the items in the Sprint Backlog. The rules of Scrum are fairly silent on what occurs each day during development. The Development Team must meet regularly for the Daily Scrum. This short meeting is for the Development Team to synchronize on what work will be executed in the next 24 hours. The Development Team should also meet with the Product Owner to groom the Product Backlog. During the Backlog Grooming, items in the Product Backlog are given additional detail, and estimates are given by the Development Team. This keeps the Product Backlog healthy so that the Product Owner can plan the software product’s release and make better decisions on the items to develop next.
During the Sprint, the Development Team completes items in their Sprint Backlog according to each item’s acceptance criteria and the team’s Definition of “Done”. This definition lists the practices and standards that must be met for every item before it can be considered complete.The definition is created by the Development Team but must be understood by the Product Owner. Both parties must understand that if work does not meet the Definition of “Done,” it is not done and cannot be released. Ideally, the Development Team collaborates with the Product Owner throughout the Sprint to ensure that all criteria are being met. If the Development Team completes their forecasted work early, they should collaborate with the Product Owner to find another suitable Product Backlog item to work on. Conversely, at the first indication that the Development Team knows that they won’t be able to complete their forecasted work, they should collaborate with the Product Owner to identify and discuss trade-offs and modify the Sprint Backlog to reflect the reality of the Sprint without sacrificing quality.
Sprint Backlog items done according the Development Team’s definition are demonstrated during the Sprint Review meeting. The Product Owner may invite various stakeholders to this meeting for their feedback on the Increment. This Product Owner and stakeholder feedback might be captured and end up as new items in the Product Backlog. Existing items may also need to be updated or removed. The Product Owner may decide to release the Increment as soon as possible or delay it. This should be a business decision. Regardless of when the Increment is released, the Development Team should always develop the Increment as though it were going to be released as soon as possible.
The last event in the Sprint is the Sprint Retrospective meeting. This meeting provides an opportunity for the Scrum Team to inspect themselves and identify what went well and what needs improving. If improvements are identified, the team should create an actionable plan for the next Sprint. Nothing is out of scope during this meeting—people, relationships, process, and tools can all be discussed. The Scrum Team may also decide to adjust its Definition of “Done” to increase product quality. After the meeting, the next Sprint begins.
The Scrum Team consists of the following Scrum roles:
The Product Owner represents the voice of the user. This means the Product Owner not only knows the product, its domain, and its vision, but also the users.
The Development Team performs all of the work (burn their business cards) required to deliver the done increment of the software product. Also, there are no subteams in Scrum, such as testing or QA.
The Scrum Master enacts the Scrum values, practices, and rules throughout the Scrum Team and even the organization. He or she ensures that the Product Owner and Development Team are functional and productive by providing necessary guidance and support. The Scrum Master is not a technical role. Having a strong background in software development is not necessary, though it can be helpful at times. Scrum Masters must really know Scrum.
The Product Owner is the visionary leader who chooses what is built, when it is ready to release, and when to stop or cancel the project. If you think of the roles in terms of providing service, the Development Team serves the Product Owner, while the Scrum Master serves both the Development Team and the Product Owner. Therefore, the Development Team has strong influence to select (that is, hire or fire) the Scrum Master. Correspondingly, the Product Owner has strong influence to select the Development Team he or she wants to turn the Product Backlog into done Increments.
© 2022 Digcode.com