The Scrum Framework :
- The Scrum Framework consists of Scrum Teams and their associated events, artifacts, and roles as defined in the Scrum Guide.
- According to the Scrum Guide, mandatory rules and principles of Scrum are Scrum Roles, Scrum Events, Sprint Goal, Product Backlog, Sprint Backlog, Increment, Definition of Done, and Monitoring progress in Sprint and Project levels. Other things are practices that can be employed in the Scrum framework and are up to the team and project and are not mandatory.
The Scrum roles :
- Product Owner
- Development Team (Developers)
- Scrum Master
The Scrum artifacts :
- Artifacts represent work or value to provide transparency and opportunities for inspection and adaption.
- Artifacts are defined by Scrum and designed to maximize transparency of key information so that everybody has the same understanding.
- Product Backlog
- Sprint backlog
The Scrum events :
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
- The Sprint is the container for all events
- According to the Scrum Guide, mandatory rules and principles of Scrum are Scrum Roles, Scrum Events, Sprint Goal, Product Backlog, Sprint Backlog, Increment, Definition of Done, and Monitoring progress in Sprint and Project levels. Other things are practices that could employ in the Scrum framework and are up to the team and project and are not mandatory.
Sprint Backlog :
- Sprint Backlog is the set of Product Backlog Items selected for the Sprint, plus a plan for the Development Team for delivering the Product Increment and realizing the Sprint Goal and is created during the Sprint Planning.
- Sprint Backlog is the combination of the Product Backlog items selected for this Sprint plus the plan for delivering them.
- Sprint Backlog is an overview of the development work to realize a Sprint’s goal. Typically a forecast of functionality, and work needed to deliver it into a “done” Increment.
- Sprint Backlog is the selected PBIs that will deliver one coherent function.
Sprint Backlog owners :
- Sprint backlog and all of its items are collectively owned by the Development Team.
- Creating the Sprint Backlog is a collaborative work that is done by the Development Team members during the Sprint Planning not before or after it.
- The Sprint Backlog belongs to the Development Team and every single item selected in a given sprint belongs to the development team. Even though individuals work on individual items, the responsibility of managing and completing the item belongs to the entire team. All Sprint Backlog Items are “owned” by the entire Development Team, even though each one may be implemented by an individual development team member.
- The Product Owner or Scrum Master should not determine or force the Development Team selecting enough items from the Product Backlog because this manner decreases their commitment as they may don’t believe that they could finish all the selected items until the end of the Sprint. It is up to the Development Team to select enough items for the Sprint without any worry about blame, outside force, or dictation, as they know the best how to do the work. Therefore, the authority of selecting enough amount of PBIs for the Sprint belongs to the Development Team.
Sprint Backlog practice :
- There are two elements in the Sprint Backlog: Sprint Backlog Items and Tasks. The ownership of both elements is shared and belongs to the Team not individual members in order to distribute the same level of accountability over all members. There is no assignment for a Sprint Backlog Item because it contains some tasks that when these tasks are done, the result will be a done Sprint Backlog Item. Tasks are assigned to the individual Team members with an agreement by all teammates.
- Development Team manages the Sprint Backlog, and makes the work that the Development Team identifies as necessary to meet the Sprint Goal.
- Development Team makes a plan with enough detail for the Sprint.
- Emergence in the Sprint Backlog occurs as the Development Team worksthrough the plan and learns more about the work needed to achieve the Sprint Goal.
- The changes are made in progress and will be understood in the Daily Scrum.
- When the Development Team is in the middle of the Sprint, they can not change the Sprint Backlog items by itself. If they find that they have overcommitted, they should inform the Product Owner to review the items together and negotiate about the scope if necessary or they might leave the Sprint Backlog intact that may lead to some undone items at the end of the Sprint, which naturally will move back to the Product Backlog.
- As work is completed in a Sprint what should happen to the Sprint Backlog ? Estimated remaining work should be updated, and when elements of the Sprint Backlog plan are no longer deemed necessary,they should be removed by the Development Team.
- In the Scrum framework, task and work are two keywords with the same meaning that are used to break down the PBIs. Tasks are the activities that need to be done by the Development Team in order to create usable and releasable Increments. As explained, Scrum is founded on an adaptive approach and the Development Team should inspect and adapt its work continuously. Therefore, each time they find a new task or work for each PBI in the Sprint Backlog they could add that task to the Sprint Backlog and even they can remove some tasks. The Development Team owns the Sprint Backlog so the Scrum Master and the Product Owner should not change it.
- Sprint Backlog contains two elements: Sprint Backlog Items and Tasks. Although changing Sprint Backlog Items is not allowed, tasks can be added or removed any time during the Sprint when the Development Team learns more about the work needed to realize the Sprint Goal. So, the Sprint Backlog can be updated during the Sprint.
- If the Development Team does not complete all Sprint Backlog Items at the end of the Sprint, the Sprint will be over with the completed items. There is no blame or other same things. However, it is a valuable fact as an input for the Sprint Retrospective to inspect if there is any problem in the development process or anything else.
- Extending or shortening a special Sprint duration is forbidden. All undone items should be re-estimated and move back to the Product Backlog and if through Product Backlog ordering, these items remain on the top of the Product Backlog, can be selected for the next Sprint.
- The Development Team does not close their planning yet so can change their Sprint Backlog even selected PBIs. Therefore, they can remove some Items from the bottom of the Sprint Backlog or inform the Product Owner and at the end of the Sprint adjust the work with Product Owner’s collaboration.
- As a tip, adding more developers to the team because of the more selected PBIs during the Sprint Planning is not acceptable because adding new members to the team will lead to a temporary reduction in the productivity. In addition, adding new members should be based on long-term needs.
Sprint Goal :
- The Sprint Goal is the commitment for the Sprint Backlog.
- Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog.
- Sprint Goal provides guidance to the Development Team on why it is building an Increment.
- Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product Backlog.
- The Sprint Goal gives the Development team flexibility regarding the functionalities implemented within the Sprint.
- The Sprint Goal get any coherence that causes the Development Team to work together rather than on separate initiatives.
- The Sprint Goal is a short expression of the purpose of a Sprint, often a business problem addressed.
Sprint Planning :
- Outputs of Sprint Planning are the Sprint Goal and Sprint Backlog which itself contains selected Product Backlog Items and their related tasks.
- The Sprint Goal is created through all Scrum Team members’ collaboration.
More informations for the Scrum PSD certification here.