Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 7 Scrum Artifacts - Coggle Diagram
Chapter 7 Scrum Artifacts
Three main artifacts for Scrum
product backlog
sprint backlog
product increment
These artifacts, or tools, all operate with the same objective in mind, which is to increase transparency and always ensure a shared understanding of the work.
Scrum artifacts provide insights to a team, which facilitate understanding of a particular project and the tasks or activities to be completed
Product backlog
The product backlog is a prioritized list of requirements, functions, and features, which a final product needs to include
As a product makes progress and is delivered to a client in increments, the backlog continues to grow as feedback is received
The product backlog is the single source of agreed requirements for a final product, and the content and validity of this list is controlled by the product owner.
Items listed on a product backlog usually comprise a description, estimate, and value and often described as ‘user stories.'
Backlog grooming, also known as product backlog refinement, is the practice of a Scrum team meeting after every sprint is completed and running through all the content of the backlog to ensure it is both relevant and useful.
Backlog grooming may include some of the following actions:
Review of the most important elements at the top of the prioritized backlog list
Removal of elements which are discovered through the most recent sprint, to no longer be relevant
Adding additional features, requirements or necessary functions which
the final product needs to include
Re-ordering items on the list as priorities of the overall project change
Formulate answers for questions posed by the client based on the most recent increments delivered
Ensure that all team members are up to date on the overall product roadmap and any necessary changes, which have been made or are still required to be made.
If you're wondering what a product backlog looks like, it is more than just a to-do list. Items on the backlog should always have the same characteristics.
All entries should always add value to the overall product and to the client.
Any entries without a clear client value should be removed
Instead, entries could include the exploration of client needs, various technical possibilities, any tasks needed to launch the product or any other functional or non-functional needs of the client or project. This could also include tasks relating to creating the environment, which the product needs to operate within.
All the entries must be prioritized in terms of importance to meet the overall objectives of the project.
This prioritization is done by the product owner and Scrum team collectively, although it is the product owner who owns this process.
When it comes to this task, value-added, costs involved as well as risks are the most common factors taken into consideration.
Items that appear first on the list will have greater detail than those towards the end of the list.
The reason for this is due to the ever-changing nature of a Scrum project. It makes little sense to update requirements that are not part of the next sprint as their requirements will change before they become more relevant.
Entries into the backlog are all estimations
In many cases, Scrum teams do not have the information readily available to provide specifics for user stories, and so estimations are considered efficient. This ties into empiricism on which Scrum revolves around.
The backlog is a living document in the sense that it is constantly changing as the needs of the project or client change.
When necessary, new items are added to the list; additional detail may be added
to existing items, items may be re-prioritized or even deleted. Although this differs from traditional methodologies of software development, this approach allows for maximum value for the client.
The backlog does not include action items or routine tasks.
The backlog should not include items that are routine or considered action items. It only includes items related to creating product value to the client.
Sprint backlog
Every sprint backlog should include at least one high priority item, a user story, which has been identified in a previous sprint's retrospective.
Updating the Sprint Backlog:
The sprint backlog should be updated on a daily basis without fail. All items for a project will be contained in the product backlog.
A team will select a high priority item and break it down into tasks that can be completed in one day, and the task selected should be achievable in one day.
As a team member, with a task you know, is achievable in one day, you will have an indication of your progress and whether you are ahead or behind rather quickly. This progress is then reported on in each daily Scrum.
What is in a Sprint Backlog?
In simple terms, a sprint backlog is a plan or guideline for the sprint.
It will usually contain user stories from the product backlog, which the team aims to complete
Each item will be broken down into a prioritized task list for the team to execute.
The Scrum team will usually use their current rate of production, or how much work they know they can complete within a given time, to predict what they can accomplish during a sprint.
Once this has been estimated, the development team can compare the total hours for every task against the capacity of the team to do a final audit on expectations for the sprint.
When is the sprint backlog finalized?
Once the items on the sprint backlog have been selected from the product
backlog and finalized, the sprint backlog is locked in, meaning no changes can be made.
Once sprint planning is complete, a team can add but not remove items from the backlog. The product owner is the only Scrum member who can remove items from a sprint backlog if they decide that it no longer adds business value. During a project, items that are removed cannot be replaced by additional tasks.
Who Manages the Sprint Backlog?
The sprint backlog is managed predominantly by the development team. It is considered the best practice to update this backlog on a daily basis so that the team constantly has a live reminder of progress, which is visual and keeps the team motivated
Should any obstacles or impediments to work occur, the development team should discuss this with the product owner as soon as this becomes apparent. Should any obstacles become apparent, the communication between the team will include managing expectations of internal and external stakeholders as well as possible solutions.
Product Increment
What is it?
Increment refers to gradual steps taken towards the completion of a goal. Product increment, in relation to the Scrum framework, refers to the sum of all the product backlog components completed during a sprint. These are combined with the increments of all other previous completed sprints. A sprint requirement is that the increment produced should be in working order and provide tangible value to the end product.
The product increment is created during a sprint as a result of all related development tasks, including design, analysis, testing, integration, and build.
The product increment is useful to all team members for a Scrum, as well as external stakeholders. It allows a product owner to assess the current return on investment (ROI) from the final functionality that will be delivered to the client at the end of each sprint.
Deliver increment at regular intervals also creates a sense of unity between team members as they receive regular feedback and recognition. The feeling of making progress and achieving success is a lot more ‘real' than traditional project management methodologies where feedback is only received at the end of a project.
Who delivers a Product Increment?
It is the development team that will deliver product increments on a regular basis.
This product increment should reflect the product owner's overall project road map as well as support the Scrum team's definition of "Done." Although it is the development team that delivers product increment and hold the majority of this responsibility, it is still a shared objective carried by the whole Scrum team.
This increment of product is then tested and integrated with previously delivered features. Prior to this testing and integration, a product is not usually considered to be "Done." Once testing is complete, the product increment is delivered to the client for feedback, which is taken on board before the next sprint commences.
Definition of "Done"
hen a product backlog point or increment is described as "Done," the entire Scrum team must reach a consensus on what "Done" means in the context of their specific project.
As with product increment, as teams mature their definitions of "Done" are usually expand to include more stringent criteria for higher quality. The longer a team works together in a solid team, the higher the quality that can be achieved.
User Stories
Examples of milestones or increments of product that could be declared "Done" are the acceptance of criteria which are met, the passing of functional tests or having code reviewed and approved.