![User Stories
• Instead of Use Cases, Agile project owners do "user stories"
• Who (user role) – Is this a customer, employee, admin, etc.?
• What (goal) – What functionality must be achieved/developed?
• Why (reason) – Why does user want to accomplish this goal?
As a [user role], I want to [goal], so I can [reason].
• Example:
• "As a user, I want to log in, so I can access subscriber content."
• story points: Rating of effort needed to implement this story
• common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.](https://image.slidesharecdn.com/fallsem2022-23swe2029thvl2022230101289referencemateriali26-09-2022scrum-221115174233-a723d8f3/85/FALLSEM2022-23_SWE2029_TH_VL2022230101289_Reference_Material_I_26-09-2022_Scrum-pptx-21-320.jpg)
FALLSEM2022-23_SWE2029_TH_VL2022230101289_Reference_Material_I_26-09-2022_Scrum.pptx
- 1. Module-5
- 2. Syllabus • SCRUM: Scrum Foundations - Scrum Roles - Scrum Master – Product Owner – Team – Scrum Meetings - Scrum Artifacts – Product Backlog - Sprint Backlog - Burn-down Charts - Scaling Scrum– Manager in Scrum and Product Backlog
- 4. Why Scrum?
- 5. What is Scrum? • Scrum: • Is an agile, lightweight process • Can manage and control software and product development • Uses iterative, incremental practices • Has a simple implementation • Increases productivity • Reduces time to benefits • Embraces adaptive, empirical systems development • Is not restricted to software development projects • Embraces the opposite of the waterfall approach…
- 6. When scrum? • When requirements are not clearly defined • When the probability of changes during the development is high • When there is a need to test the solution • When the client’s culture is open to innovation and adapts to change
- 7. Scrum Origins • Jeff Sutherland • Initial scrums at Easel Corp in 1993 • IDX and 500+ people doing Scrum • Ken Schwaber • ADM • Scrum presented at OOPSLA 96 with Sutherland • Author of three books on Scrum • Mike Beedle • Scrum patterns in PLOPD4 • Ken Schwaber and Mike Cohn • Co-founded Scrum Alliance in 2002, initially within Agile Alliance
- 8. SCRUM • An agile approach to software development that enables us to focus on delivering the highest business value in the shortest time • Allows us to rapidly and repeatedly inspect actual working software. • Scrum methodology makes progress in a series of “sprints” and it takes a typical duration of 2 to 3 weeks or a calendar month at most, • product designing, coding, and testing were performed during the sprint 10/10/2019
- 9. Scrum Framework •T eam Roles •Product owner •Scrum Master Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Burndown charts
- 10. 10/10/2019
- 11. 10/10/2019
- 12. Sequential vs. Overlap Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time Requirements Design Code Test
- 13. Scrum Roles • Product Owner • Possibly a Product Manager or Project Sponsor • Decides features, release date, prioritization, • Scrum Master • Typically a Project Manager or Team Leader • Responsible for enacting Scrum values and practices • Remove impediments / politics, keeps everyone productive • Project Team • 5-10 members; Teams are self-organizing • Cross-functional: QA, Programmers, UI Designers, etc. • Membership should change only between sprints
- 14. Activities involved • Sprint planning meeting: the sprint prioritization, evaluation of product backlog, the design of sprint goal, created the sprint backlog tasks from product items and later the estimation of sprint backlog in hours was judged. • Product owner does this • Sprint review:Team conducts this on product • Sprint retrospective Team conducts retrospective on process • Daily scrum meetings Scrum master conducts the meeting 10/10/2019
- 15. Sprint • Sprint: time-boxed event of one month or less, that serves as a container for the other Scrum events and activities. • Sprints are done consecutively, without intermediate gaps.
- 16. Sprint Planning • time-boxed event of 8 hours, or less, to start a Sprint. • serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog. • To determine the most important subset of product backlog items to build in the next sprint, the product owner, development team, and Scrum Master perform sprint planning 10/10/2019
- 18. Sprint Planning Meeting Sprint planning meeting Sprint prioritization • Analyze/evaluate product backlog • Select sprint goal Sprint planning • Decide how to achieve sprint goal (design) • Create sprint backlog (tasks) from product backlog items (user stories / features) • Estimate sprint backlog in hours Sprint goal Sprint backlog Business conditions Team capacity Product backlog T echnology Current product
- 19. Daily Scrum Meeting • Parameters • Daily, ~15 minutes, Stand-up • Anyone late pays a $1 fee • Not for problem solving • Whole world is invited • Only team members, Scrum Master, product owner, can talk • Helps avoid other unnecessary meetings • Three questions answered by each team member: 1. What did you do yesterday? 2. What will you do today? 3. What obstacles are in your way?
- 20. Product Backlog • The requirements • A list of all desired work on project • Ideally expressed as a list of user stories along with "story points", such that each item has value to users or customers of the product • Prioritized by the product owner • Reprioritized at start of each sprint This is the product backlog
- 21. User Stories • Instead of Use Cases, Agile project owners do "user stories" • Who (user role) – Is this a customer, employee, admin, etc.? • What (goal) – What functionality must be achieved/developed? • Why (reason) – Why does user want to accomplish this goal? As a [user role], I want to [goal], so I can [reason]. • Example: • "As a user, I want to log in, so I can access subscriber content." • story points: Rating of effort needed to implement this story • common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.
- 22. Sample Product Backlog Backlog item Estimate Allow a guest to make a reservation 3 (story points) As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run RevPAR reports (revenue- per-available-room) 8 Improve exception handling 8 ... 30 ... 50
- 23. Sample Product Backlog 2
- 24. Sprint Backlog • Individuals sign up for work of their own choosing • Work is never assigned • Estimated work remaining is updated daily • Any team member can add, delete change sprint backlog • Work for the sprint emerges • If work is unclear, define a sprint backlog item with a larger amount of time and break it down later • Update work remaining as more becomes known
- 26. Sample Sprint backlog Tasks Mon Tue Wed Thu Fri Code the user interface 8 4 8 Code the middle tier 16 12 10 4 Test the middle tier 8 16 16 11 8 Write online help 12 Write the Foo class 8 8 8 8 8 Add error logging 8 4
- 28. Burn-down Chart • a chart which shows the amount of work which is thought to remain in a backlog. • Time is shown on the horizontal axis and work remaining on the vertical axis. • Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart
- 29. Burn-up Chart: • A chart which shows the amount of work which has been completed. • Time is shown on the horizontal axis and work completed on the vertical axis.
- 30. Sprint Burndown Chart • A display of what work has been completed and what is left to complete • one for each developer or work item • updated every day • (make best guess about hours/points completed each day) • variation: Release burndown chart • shows overall progress • updated at end of each sprint
- 32. Hours Tue Wed Thu Fri Tasks Mon Tue Wed Thu Fri Code the user interface 8 4 8 Code the middle tier 16 12 10 7 Test the middle tier 8 16 16 11 8 Write online help 12 50 40 30 20 10 0 Mon
- 33. Burndown Example 1 No work being performed Sprint 1 Burndown 0 10 20 30 40 50 60 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Days in Sprint 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Hours remaining
- 35. Burndown Example 3 Work being performed, but too fast! Sprint 1 Burndown 0 10 20 30 40 50 60 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Days in Sprint 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Hours remaining
- 36. The Sprint Review • Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features or underlying architecture • Informal • 2-hour prep time rule • No slides • Whole team participates • Invite the world
- 37. Scalability • Typical individual team is 7 ± 2 people • Scalability comes from teams of teams • Factors in scaling • Type of application • Team size • Team dispersion • Project duration • Scrum has been used on multiple 500+ person projects
- 38. Scrum of scrums The scrum of scrums is a technique to scale scrum up for multiple teams working on the same product, allowing teams to discuss progress to on their interdependencies, focusing on how to coordinate delivering software, especially on areas of overlap and integration. Depending on the cadence (timing) of the scrum of scrums, the relevant daily scrum for each scrum team ends by designating one member as an ambassador to participate in the scrum of scrums with ambassadors from other teams.
- 39. Scalability This should run similar to a daily scrum, with each ambassador answering the following four questions: What impediments have my team resolved since we last met? What impediments will my team resolve before we meet again? Are there any impediments slowing my team down or getting in our way? Are we about to put something in another team's way?
- 40. Scaling: Scrum of Scrums
- 41. Scrum of Scrums • To coordinate the activities in all the teams: • Replication of key roles in each of the teams, such as the PO, ScrumMaster, and technical lead. • the alignment of iterations: • for example, plan the deployment of a new version of the product on a specific date
- 42. Scrum of Scrums • To coordinate the activities in all the teams: • To hold staggered daily meetings • sequencing the daily meetings so that representatives of each team can potentially participate in the other teams' daily meetings, to identify dependencies and risks and to find specific skills. • fact is to realize that the technique is scalable: • Creating a Scrum of Scrums of Scrums! • For example, imagine a project of 100 people. • In this case, we would have 10 teams of 10 people; • however, 10 teams are more than the recommended number of 9. • Then we would create another team taken to a higher level
- 43. Project Organization - Multiple Teams • Scrum in a large-scale project • increase the number of teams in the same location • the number of teams should not grow too fast • Best is to start with a single team and after the first sprints have been completed adding a small number of other teams
- 44. Project Organization - Multiple Teams • For creating new teams there are two possibilities: • Splitting an existing team into new teams and add new members • Advantage: The required know-how is already available in the team and the team can get productive faster. • Drawback: Already working teams are torn apart. • Adding completely new teams • Advantage: These existing teams can continue with their work without much disruption. • Drawback: It will take longer to build up the necessary system-know-how in the new Scrum Team.
- 45. Project Organization - Multiple Teams • Independent from the decision how to add new teams the following rules should be followed: • Start with a small number of teams • Always wait until a foundation is build and the teams have stabilized • Increase the number of teams in small steps
- 46. Project Organization – Distributed Teams • More often communication obstacles will occur and special care has to be taken to introduce and involve all team members adequately. • New team members could e.g. team, preferably even temporarily added to an existing in another location. • With this approach the know-how is transferred and personal relationships with people in other teams locations and build.
- 47. Virtual Teams-Distributed environment • Another possibility for distribution is that the team itself is spread over multiple locations. • Called a "virtual team". • Challenge: • Ensure good communication between the team members since some people might not be able to physically participate in meetings or have no access to "communication helpers" like the Sprint Board • Collaboration tools can be assisted • video conferencing
- 48. Scrum Product Owner Team • Proper communication between the Scrum Product Owner and the team is crucial for successful implementation of the project • multiple Scrum Product Owners working together to ensure availability • Ideally there is one dedicated Scrum Product Owner per team.
- 49. Scrum Product Owner Team • One of the Scrum Product Owners should be assigned the role of the 'Chief Scrum Product Owner' who is responsible to ensure that the product is developed in a coordinated fashion. • For complete Requirement engineering: • Add other roles and stakeholder like architects or customer representatives • All Scrum Product Owners should work within a single Scrum Product Backlog containing all stories relevant for the project.
- 50. Component or Feature Teams • When distributing work we can slice the teams in different manners: as • Component teams: Each team is only responsible for the implementation of dedicated components in the system. • Feature teams: Fully responsible for implementation of user stories as contained in the Scrum Backlog
- 51. Component Team • To finish a user story it is in most cases necessary to split the stories into smaller pieces that could be implemented within a single component. • The resulting dependencies between the teams make integration on a regular base necessary. • In many cases a single user story cannot be finished within a single sprint as implementation in one team depends on the results of other stories in other team that are not yet available. • This is called "Pipelining" and should be avoided as far as possible.
- 52. Component teams • Advantage: It is easier to ensure proper architecture of the system • Disadvantage: People specialize only on small parts of the system and knowledge about the system as a whole might get lost. • Without this knowledge local optimization might take place since the team might sometimes make decisions that are optimized for the single component but better solutions from a system perspective could have been made.
- 53. Feature Teams • The team is no longer sliced along system components but implement everything what is necessary to finish the story. • Feature teams have to be interdisciplinary and ideally can act completely autonomous. • Advantage: System-knowledge is spread and integration is easier. • Disadvantage: More difficult to ensure consistency of the system architecture and it might be difficult or takes time to ensure that enough knowledge is available in all teams.
- 54. Component and Feature Teams • In reality many larger projects use both: dedicated Component teams and Feature teams • Team C is a Component team and provides necessary infrastructure services to the other teams that are used as Feature teams. • Team C does not directly implement user stories but get the requirements from the user stories committed by the Feature teams. • This allows minimizing the number of required people with expert knowledge (e.g. databases know- how).
- 55. Scrum vs. Other Models