Scrum - Artifacts
Definition of Done
Done should include everything we need to do for all items of this increment release, including user acceptance testing.
The definition of ‘done’ is a well-understood and clearly documented definition of items that must be established to mark a story (or iteration or project) to be complete. Getting a story to a completed state per the definition of done should be the goal of a team and should be used as the basis for planning.
Assessment/Checklist allows work to be defined as “Done.”
Defined by the development team.
Varies per team: Understandable for the team.
Helps to define how many items can be selected for Sprint.
More mature teams: More stringent criteria.
Work
The work a development team does is based upon
the fact that the business will ask for “stuff” to:
Make themselves more efficient.
Deliver better customer service.
Increase sales and profitability.
Take advantage of a market opportunity.
Spur growth.
Become more competitive.
Product Backlog
The Product Backlog is used to document the wants and needs for “stuff,” which is prioritized by how much value it is to the business
Different people in the business will ask for different “stuff.”
Not everything that is asked for has value to the business.
Some things may be valuable only to the person asking rather than to the entire business.
By prioritizing value to the business, non-value add or less-value add items are eliminated or moved to the bottom of the list.
The list is worked based on what the highest priority or value is to the business.
Contains any/all requests from the business for new items/changes to existing items.
Ordered list of all user requests/requirements.
Each entry is called: Product Backlog Item (PBI).
Items are arranged based on value to the business.
Each item takes the form of user stories.
Very large PBIs are called Epics.
Epics are broken down into smaller digestible chunks before being considered for work being done.
Product Backlog is constantly re-evaluated and re-ordered, and items added or removed in a process are called Product Backlog Grooming.
Sprint Backlog
A Sprint Backlog is a prioritized list of user stories, bugs, and technical tasks that a Scrum team plans to complete during a Sprint
Sprint Backlog Items (SBI)
Ordered list of requirements
Considerations
Risk.
Dependencies.
Deadline.
Business Value
Value-Orientation vs. Result-Orientation
Value orientation focuses on the principles and values that guide decision-making. It places a higher priority on ethics, morals, and the impact of decisions on stakeholders, rather than on achieving specific outcomes or results. People who are value-oriented are often motivated by a desire to do what is right, and to make decisions that align with their personal values and beliefs
Results orientation, on the other hand, places a higher priority on achieving specific outcomes or results. It focuses on setting and achieving goals, meeting deadlines, and achieving measurable outcomes. People who are results-oriented are often motivated by a desire to succeed, to achieve their goals, and to be recognized for their achievements
Chosen based on the estimated amount of work required to complete.
List of work for immediate execution.
Pulled from Product Backlog.
Chosen by the development team.
Choose from the highest priority value.
Only pull into sprint backlog the amount of work that the team believes they can reasonably accomplish successfully.
Once chosen, the Sprint Backlog list is frozen — “nothing can be added” until this list is completed in the next time-box.
List of work to be performed during this Sprint.
Created for the current sprint by selecting items from the product backlog during the sprint planning session.
Prioritized with a plan for accomplishment
Sprint Backlog items are broken down into tasks with each task having a planned maximum duration of two days.
Sprint Backlog is listed on the Task Board.
Tasks are tracked progressively to completion.
Task Board is re-evaluated every day during the daily standup.
Product Backlog --> Item Forecast
Fix Credit System
Filter Customer List
Help Tips
How are items chosen
It is chosen during the Sprint Planning meeting by the Development Team in collaboration with the Product Owner
Sprint Task --> To-Do
Sprint Task --> In-Process
Sprint Task --> Done
Task Board / Sprint Board / Kanban Board
Interactive listing of work to be/being performed during Sprint.
Used daily to identify workflow.
Displayed in a common work area.
Burn-Down Chart
Shows remaining work in Sprint Backlog.
Simple view of Sprint progress (daily).
Assessed daily.
Displayed in the common work area.
Sample Burndown Chart
Completed tasks
Remaining effort
Ideal burndown
Remaining tasks
To update a Burn-Down chart, follow these steps:
Determine the amount of work remaining: Start by estimating the remaining work for each task or user story in the current sprint. This can be done using a task board or backlog.
Calculate the total amount of work: Add up the remaining work for all the tasks or user stories in the current sprint.
Determine the time remaining: Estimate the number of days remaining in the sprint.
Plot the chart: Plot the total amount of work on the vertical axis and the time remaining on the horizontal axis. Draw a line connecting the starting point (total work remaining at the beginning of the sprint) to the ending point (zero work remaining at the end of the sprint).
Update the chart: Update the chart daily or as frequently as necessary by adjusting the total amount of work remaining based on progress made on each task or user story. The goal is to see the line trending downwards towards zero as work is completed.
User Stories
Describes what the user needs to do in the job function.
Used as the basis for defining the function of the business system.
Used as a basis for requirements gathering.
Explain, the “who,” “what,” and “why” of a requirement.
Often written on small note cards.
User’s primary way of influencing the functionality of the system to be built.
One or more sentences are written in everyday business language.
Becomes the representation of a Product Backlog Item (PBI).
To be complete, user stories should contain
name
brief narrative
acceptance criteria
any defined conditions
Story format: "As a < user type >, I want to < goal or objective > so that < desired result >.”
Gathering User/Business Needs
User Story - Priority and Digestibilit
Epics are broken down into smaller stories, and then broken down further into tasks.
Story Points
Choosing enough work to fill up a full sprint
Based on relative effort.
Show only the relative size of the item - not the time to complete.
Teams pick a simple, agreed-upon basis.
Used for Estimation Activities.
Planning Poker
Determining the amount of work for each Product Backlog Item
Based on the Fibonacci Sequence:
Each numbered card represents the amount of work the team member believes this item represents.
Each development team member is issued one set of cards.
If when hands are shown, there is not a clear agreement on the amount of work involved, high and low bidders will explain why they chose that bid.
The team will re-vote until they reach a consensus.
Fibonacci Sequence
The Fibonacci sequence is a type series where each number is the sum of the two that precede it. 1, 1, 2, 3, 5, 8, 13, 21, 34, 55
Last updated