Downloaded 63 times
Scrum artifacts
The document discusses scrum artifacts, emphasizing their role in transparency and adaptability within projects. It covers key components such as the product backlog, sprint backlog, and product increment, detailing how they function and their importance in managing project tasks. Additionally, it outlines best practices for maintaining and grooming the product backlog to ensure effective sprint planning and execution.
More Related Content
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Scrum artifacts
- 1. SCRUM ARTIFACTS What arethey and why they are important Presentation by Gul Zaman Ilyas
- 2. About Presenter Email: zamanilyas@hotmail.com| Ph. #: (+92) 323 141 6914 Professional Summary: A Certified Scrum Master & MCSD possessing almost 18+ Total Years of Professional IT Work Experience & almost 10 Years of Project Management related experience. Overall possessing experience in Entrepreneur-ship, IT Operations, IT Infrastructure, Software Architecture & Development, IT Consultancy, Cloud Platforms, Virtualization, Networks and much more. Tools Stack: Communication, Training, Networks, IT Operations, IT Infrastructure, Microsoft Technologies, Linux, Cloud (Public, Private & Hybrid), Virtualization, AWS, Azure
- 3. SCRUM Artifacts Scrum’s artifactsrepresent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact. The Scrum Artifacts are: – Product Backlog – Sprint Backlog – Increment / Product Increment
- 4. Product Backlog –What is a Product ■ What constitutes a product? – IVAN-X, MS Office vs MS Excel, Word, etc. ■ Simple definition usually works… – A product is something of value that a customer would be willing to pay for and something “we” would be willing to “package” up and sell ■ Component - Teams bump up against this simple definition – Customer buying the component? – Component going into multiple products? ■ Leads to a rabbit hole!
- 5. Product Backlog –What is a Product? ■ Large Products utilize Hierarchical Product Backlogs ■ Multiple, interchangeable teams can utilize one Product Backlog ■ Multiple, non-interchangeable teams need to have a team-specific view of the single Product Backlog
- 6. Product Backlog –What is a Product? ■ Case 1 on the left side of image where Multiple Products best handled by one or more teams working exclusively on a single product backlog ■ Case 2 on the right side of image where Occasionally, not ideal, one team works on multiple Product Backlogs
- 7. ■ The ProductBacklog – Is a prioritized list of desired product functionality (artifacts) – Centralized & Shared understanding of what to build and its build order – Is highly visible to all Scrum participants – Exists for products being built, enhanced, or supported – The Product Backlog is the master list of all functionalities desired in the product – It is NOT necessary to start a project with a lengthy, upfront effort to document all requirements. – Product backlog items can be ■ Technical tasks – Bugs, Enhancements, Issues – E.g. "Refactor the Login class to throw an exception" ■ User-centric – User Stories – E.g. “Subscription should be charged through Direct Carrier Billing (DCB)" – XP User Stories is a good approach to fill the Product Backlog – Product Owner writes and prioritize the product backlog – Scrum master can update it along the sprints 7 Scrum Artifacts
- 8. 8 Estimates have been developedby the developers but it is understood that they are very imprecise and are useful only for rough assignments of tasks into the various sprints. - Point Estimation - Time Estimation Sample Product Backlog
- 9.
- 10. Product Backlog Items ■Product Backlog consists of backlog items, called PBIs, backlog items, or just items ■ Most PBIs: – Are features/functionalities that will have tangible value to the user or customer – Often are written as User Stories (but Scrum does not dictate a format) ■ Examples of PBIs include: – Features – Change – Defects – Technical Work – Knowledge Acquisition (proof of concept)
- 11. PBI Examples PBI TypeExample Feature As a customer service representative I want to create a ticket for a customer support issue so that I can record and manager a customers request for support. Change As a customer service representative I want the default ordering of search results to be by last name instead of ticket number so that it’s easier to find a support ticket. Defect Fix defect #256 in the defect-tracking system so that special characters in search terms wont make customer searches crash. Technical Improvement Move to the latest version of the Oracle DBMS Knowledge Acquisition Create a prototype or proof of concept of 2 architectures and run three tests to determine which would be a better approach for our product.
- 12. Good Product BacklogCharacteristics DEEP acronym coined by Roman Pichler (2010) & Mike Cohn (MountainGoatSoftware) ■ Detailed Appropriately ■ Emergent ■ Estimated ■ Prioritized
- 13. Product Backlog Characteristic– Detailed Appropriately ■ Not all PBIs are at the same level of detail at the same time ■ PBIs being prepared to work on should be small, very detailed, and near the top of the prioritized list ■ Other PBIs are lower in the list, larger in size, and less detail ■ Larger PBIs, EPICs, are decomposed into sprint-ready items in a just-in-time fashion
- 14. Product Backlog Characteristic- Emergent ■ While a product is being built, enhanced, or supported, its backlog is never complete or frozen ■ Product Backlog is continuously being updated based on a stream of economically viable information ■ Therefore, the Product Backlog’s structure is fluid needing rebalancing and prioritizing based on new information
- 15. Product Backlog Characteristic- Estimated ■ Each PBI has a size estimate associated with it ■ Product Owner uses the estimate as one input to prioritization ■ Large PBIs near the top of the list indicate refinement is necessary ■ Most PBIs are estimated in either story points or ideal days (See Chapter 7 for details) ■ Estimates should be reasonably accurate without being overly precise ■ Smaller, near top of the list PBIs will have smaller, more accurate size estimates ■ Epics, larger PBIs, are more difficult to estimate accurately so some teams use T-shirt size estimates (L, XL, XXL, etc.)
- 16. Product Backlog Characteristic- Prioritized ■ Not necessary to actually prioritize items near bottom of the list ■ Useful to prioritize PBIs that are candidates for the next few sprints or to a first release ■ Too much time focus on the future is to be avoided ■ Of course changes can shuffle PBIs
- 17. Product Backlog Grooming ■Product Owner leads grooming & is the final decision maker ■ Input from stakeholders, ScrumMaster, Dev. Team ■ Dev. Team should allocate up to 10% of its time each sprint for grooming ■ Grooming - Proactively manage, organize, and administer the Product Backlog to accomplish DEEP characteristics ■ Grooming activities: – Creating & Refining PBIs – Estimating PBIs – Prioritizing PBIs ■ Scrum framework does not specify when grooming should take place ■ Waterfall development tries to capture detailed requirements up front so little or no grooming is scheduled (yet it always occurs!) ■ Scrum expects an uncertain environment so team must be prepared to constantly inspect and adapt ■ Initial grooming occurs as part of the release-planning activity ■ On-going grooming can occur once-a-sprint, every week, or even daily
- 18. Product Backlog Grooming ■Grooming the backlog should ensure that PBIs at the top of it are ready to move into a sprint ■ Some teams establish a definition for Ready similar to Done to help formalize grooming ■ Example of a Ready Checklist
- 19. Question In product refinement,the first case is consider as ______ for long-term release planning to be done. A. Existing product B. Refined product C. New product D. None of these
- 20. Question In product refinement,the first case is consider as ______ for long-term release planning to be done. A. Existing product B. Refined product C. New product D. None of these Correct Answer: C
- 21. Product Backlog FlowManagement ■ Product Backlog is crucial to achieving fast, flexible value-delivery in the face of uncertainty which always exists in projects ■ Release planning can be visualized as a line through the product backlog ■ Specific release can be partitioned into 2 more lines – must have and nice to have ■ Won’t have is below the release cut-off line
- 22. Question For many SCRUMteams is most workable to have __________ worth of user stories ready to go. A. 2 to 3 Sprints B. 3 to 5 Sprints C. 5 to 7 Sprints D. None of these
- 23. Question For many SCRUMteams is most workable to have __________ worth of user stories ready to go. A. 2 to 3 Sprints B. 3 to 5 Sprints C. 5 to 7 Sprints D. None of these Correct Answer: A
- 24. Product Backlog FlowManagement ■ For a Sprint, the Product Backlog can be viewed as a pipeline of requirements that are flowing into the Sprint ■ A problem arises if there is a mismatch or unevenness between inflow and outflow in this pipeline – Too slow – pipeline could run dry – Too fast – may cause rework/throw away as more is learned ■ Rule of thumb for many teams is to have 2 to 3 sprint’s worth of user stories ready to go
- 25. Summary ■ Crucial Roleof the Product Backlog in achieving fast, flexible, value-delivery in the presence of uncertainty ■ Structural and Process issues surrounding the Product Backlog – Types of items – How to groom ■ Which and how many Product Backlogs
- 26. Sprints ■ Scrum organizeswork in iterations or cycles, called Sprints, of up to a calendar month ■ Sprint key characteristics: – Timeboxed – Short and consistent duration – Goal should not be altered once started – Must reach the end-state specified by the team’s definition of done
- 27. ■ The SprintBacklog – The list of tasks that the Scrum team is committing that they will complete in the current sprint. – Items on the sprint backlog are drawn from the Product Backlog, and Detailed into smaller list of things needed to be done – Selected based on the priority of in the product backlog – Due by next sprint !! ■ Sample Sprint Backlog – As a user, I want to reserve a hotel room ■ Add hotel table to the database – 1 hr ■ Write Ajax code to display reservation – 4 hrs ■ Write code to enter reservation in the database – 4 hrs – As a user, I want to cancel a reservation ■ Display the user’s current reservations – 4 hrs ■ Add a cancel button next to each reservation – 1 hr 27 Scrum Artifacts
- 28. Some facts aboutSprint Backlog 1) The Sprint Backlog is created anew for each Sprint 2) The Sprint Backlog is created by The Team Itself 3) Only tasks that The Team agrees to commit to is added to the sprint. 4) Tasks are broken down into manageable pieces and given estimates. 5) Team members signs up for tasks. 6) Tasks can be added or removed during the sprint. Scrum Artifacts – Sprint Backlog
- 29. Sprint Backlog /Sprint Task Board https://www.youtube.com/watch?v=Ti2g66b7MUo
- 30.
- 31. Questions _______ are createdduring second half of the sprint planning meeting A. Sprint B. Task C. User stories D. Sprint backlog
- 32. Questions _______ are createdduring second half of the sprint planning meeting A. Sprint B. Task C. User stories D. Sprint backlog Correct Answer: D
- 33. Questions During sprint, the___________list are identified and used to list out task by scrum team. A. Scrum product B. Sprint review C. Sprint backlog D. Sprint retrospective
- 34. Questions During sprint, the___________list are identified and used to list out task by scrum team. A. Scrum product B. Sprint review C. Sprint backlog D. Sprint retrospective Correct Answer: C
- 35. Questions ______ are createdin first half of the sprint planning meeting according to scrum master A. Sprint backlog B. Scrum C. Backlog D. Sprint Goal
- 36. Questions ______ are createdin first half of the sprint planning meeting according to scrum master A. Sprint backlog B. Scrum C. Backlog D. Sprint Goal Correct Answer: D
- 37. Definition of Done ■Definition of Done (applies to the product increment) can evolve over time as organizational impediments or limitations may necessitate – Earlier sprints may have a definition of Done that is somewhat different than later sprints due to this – Leaving an activity out of a sprint (such as performance testing) could have a backwards ripple effect when that activity is actually performed ■ Definition of Done versus Acceptance Criteria – Each product backlog item in a sprint should have a set of conditions of satisfaction (acceptance criteria) for the Product Owner – Acceptance criteria are item specific and in addition to definition of Done – Completed or Accepted (not done) are terms used when Product Backlog items pass their acceptance criteria
- 38. Product Increment The Incrementis the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done”, which means it must be in usable condition and meet the Scrum Team’s Definition of “Done”. Scrum Artifacts It must be in usable condition regardless of whether the Product Owner decides to actually release it.
- 39. Velocity Velocity, the amountof total work that can completed in a sprint. Typically a full time resource on a 2 week sprint has 8 story points (8 days out of 10 total days so 80% allocation).
- 40. Product Release A veryhigh-level plan for multiple Sprints (e.g. three to twelve iteration) is created during the Release planning. It is a guideline that reflects expectations about which features will be implemented and when they are completed. It also serves as a base to monitor progress within the project. Releases can be intermediate deliveries done during the project or the final delivery at the end. To create a Release Plan the following things have to be available: ■ A prioritized and estimated Scrum Product Backlog ■ The (estimated) velocity of the Scrum Team ■ Conditions of satisfaction (goals for the schedule, scope, resources) ■ Depending on the type of project (feature- or date- driven) the release plan can be created in different ways: ■ If the project is feature-driven, the sum of all features within in a release can be divided by the expected velocity. This will then result in the number of sprints needed to complete the requested functionality.
- 41. Product Release ■ Ifthe project is date-driven we can simply multiply the velocity by the number of Sprints and we'll get the total work that can be completed within the given timeline. ■ Like the Scrum Product Backlog the Release plan is not a static plan. It will change during the whole project when new knowledge is available and e.g. entries in the Scrum Product Backlog are changed and re-estimated. Therefore the Release Plan should be revisited and updated in regular intervals, e.g. after each Sprint.