_edited_edited.png)
Scrum is an agile approach to software development, which focuses on delivering valuable business features in short development iterations of 2 to 4 weeks.
Scrum Team:
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Developers in scrum are anyone important to create increments (usable feature/enhancement) of value for a product. The Developers' team in Scrum includes any skill set needed to create value - Coder, Tester, UX, BA, Operations, Marketing, Sales Expert, etc.
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment in each Sprint. As per the scrum guide, the Developers are always accountable for:
● Creating a plan for the Sprint, Sprint Backlog.
● Ensuring quality by adhering to a Definition of Done.
● Adapting their plan each day toward the Sprint Goal.
● Holding each other accountable as professionals.
Scrum teams have two defining characteristics – they are cross-functional, meaning they include every skill set necessary to get the job done and they are self-managing, the team is expected to figure out how best to get the job done and who does what, when, and how.
Scrum Artifacts:
An artifact in general, is one of many kinds of tangible by-products produced during the development of software. Scrum artifacts play a vital role in building a picture of Scrum team progress, so let’s talk about what exactly that role involves and why it’s useful. Scrum artifacts keep all team members coordinated as they work toward the sprint goal. Even as major or last-minute changes crop up, Scrum artifacts evolve to capture the key information the team needs at certain checkpoints to get to the finish line. It is done through Scrum meetings and using tools like Scrum boards.
The three Scrum artifacts are the product backlog, the sprint backlog, and the product increment.
Each Scrum artifact answers a question:
Product backlog: What will the Scrum team work on next sprint?
Sprint backlog: What will the Scrum team work on this sprint and how will they get it done?
Product increment: What will the Scrum team have made by the end of this sprint and how will they know it’s “done”?
Product Backlog:
A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. Product Backlog items that can be done by the Scrum team within one Sprint are ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after product backlog refinement.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. All work items related to the product or project should be included in the backlog. The specific type of items and initiatives will vary from team to team, but the following items usually belong in the backlog:
New features
New feature ideas
Bugs of all levels and severity
Bug fixes
Feature improvements
Feature requests from customers and stakeholders
Design changes
UX issues
Technical debt
Infrastructure changes
The Developers who will be doing the work are responsible for the sizing of the Product backlog. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Commitment: Product Goal
The Product Goal describes the future state of the product which can serve as a target for the Scrum team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
Sprint Backlog:
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout Sprint. It should have enough detail so that they can inspect their progress in the Daily Scrum.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the scrum team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than what they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
Product Increment:
An Increment is the latest stable and usable version of a product. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
Multiple Increments may be created within a Sprint. However, an Increment may be delivered to stakeholders before the end of the Sprint. Work cannot be considered part of an Increment unless it meets the Definition of Done.
Commitment: Definition of Done
The Agile definition of done is a collection of criteria that must be completed for a project to be considered “done.” It is essentially a checklist used by Scrum teams to create a shared understanding of what is required to make a product releasable.
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done that is appropriate for the product.
Scrum Events:
The Sprint is a container for all the events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Optimally, all events are held at the same time and place to reduce complexity.
1. Sprint Planning Meeting:
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning addresses the following topics:
Topic One: Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that ensures why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized before the end of Sprint Planning.
Topic Two: What can be Done in this Sprint?
Through discussion with the Product Owner, the scrum team then selects items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process.
Selecting how much can be completed within a Sprint may be challenging. However, the more the team knows about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
Topic Three: How will the chosen work get done?
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. The developers in the scrum team turn Product Backlog items into Increments of value.
The Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them are together referred to as the Sprint Backlog.
2. Daily Scrum:
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. It focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plans. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of Sprint’s work.
3. Sprint Review:
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session, and the Scrum Team should avoid limiting it to a presentation.
4. Scrum Retrospective:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went about individuals, interactions, processes, tools, and their Definition of Done. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
Any changes or improvements addressed may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective concludes the Sprint.
Comments