PM 400 Week 3 Scrum Roles, Events and Artifacts Example

Sprint Seven at the Library: How Scrum's Accountabilities, Events and Artifacts Work for a Mobile App Team

[Student Name]

University of Phoenix

PM/400: Agile Management and Tailoring

Week 3 Assignment

[Instructor Name]

[Date]

Desert Sky Library District, its Scrum team and every figure are composites written for a model paper.

Desert Sky Library District, the made-up southern Arizona library system in this course, has been rebuilding its mobile app with an agile approach since Week 1. The team adopted Scrum, a lightweight framework that the Scrum Guide describes as helping people and teams generate value through adaptive solutions to complex problems (Schwaber & Sutherland, 2020). The app team is now in its seventh two-week sprint. This paper uses that sprint to describe how Scrum's accountabilities, events and artifacts work together.

The Three Accountabilities

The product owner, Mei Tanaka from digital services, is answerable for the value of the app. She owns the product backlog, decides its order and explains each item to the team. Branch managers and the deputy director bring her requests, but she decides what comes first.

The scrum master, Josh Abernathy, is answerable for the team's effectiveness with Scrum. He coaches the team, removes obstacles, makes sure events happen and stay useful and helps the district understand how to work with the team. He does not assign tasks.

The developers, four from the outside firm plus the designer and the library's systems analyst, are answerable for creating a usable increment each sprint that meets the definition of done. They choose their own methods and split the tasks among themselves. The guide recommends a small team, typically ten or fewer people, so communication stays direct.

The Product Goal and the Sprint Goal

The product goal, agreed with the deputy director, is an app patrons rate at four stars or more, used for at least 40 percent of holds. Sprint 7's goal supports it: patrons can see and pay fines of up to $20 in the app. Fines under $20 make up most balances that block borrowing, and paying them at a desk discourages patrons from returning.

Sprint Planning

Planning, timeboxed at four hours for a two-week sprint, worked through the purpose of the sprint, the items that could fit inside it and the plan for building them. Tanaka explained the goal and the backlog items at the top. The developers selected eight items they believed they could finish, based on their recent average of about 34 points per sprint, and broke them into tasks: connecting to the district's payment processor, showing the fine balance, a payment screen, receipts by email, error handling and tests. The sprint backlog that resulted holds the goal, the selected items and the plan to deliver them.

The sprint goal is what lets the team drop a task and still succeed, because success is the goal, not the list.

The Daily Scrum

Each morning the developers meet for 15 minutes to inspect progress toward the goal and adjust the plan. Stray et al. (2016) studied daily stand-up meetings in several companies and found that they helped teams coordinate and solve problems but could become status reports to a manager that left members disengaged. Abernathy keeps the meeting with the developers and focused on the goal. On day four, the systems analyst said the district's information security officer had not yet reviewed the payment connection, a step the district requires before any payment feature goes live. Abernathy took the obstacle to the officer the same day, and the review was scheduled for day six.

The Sprint Review

On day ten, the team showed the working payment feature to the patron panel, two branch managers and the deputy director. Panelists paid test fines on their own phones. Two asked for a reminder before fines are added, and a branch manager asked whether patrons could pay for lost items. Tanaka added both to the product backlog and ordered the reminder ahead of lost-item payments. The review is a working session that updates the product backlog, not an approval meeting.

The Sprint Retrospective

The retrospective, held after the review, asked how the sprint went for people, interactions, processes, tools and the definition of done. The team agreed that the security review delay could have been avoided and decided to add security review to the definition of done for any feature touching patron accounts or payments, so it would be planned from the start.

The Three Artifacts and Their Commitments

The product backlog is the ordered list of everything that might improve the app, with the product goal as its commitment. The sprint backlog is the developers' plan for the sprint, with the sprint goal as its commitment. The increment is the sum of usable work completed, and its commitment is the definition of done. Desert Sky's definition requires code review, automated tests passing, accessibility checks, Spanish translation of new screens and, now, security review where relevant. The fines feature met it on day nine and was released to app stores after the review.

How the Elements Fit Together

The framework works because each element feeds the next. The product goal shapes how Tanaka orders the product backlog; the top of that backlog becomes the material for planning; planning produces the sprint goal and sprint backlog; the daily meeting protects the goal; the review turns what the team learned into a reordered product backlog; and the retrospective improves the way the next sprint will run. Removing any one breaks the chain. When the team briefly skipped a retrospective in Sprint 4 to finish work, the same testing bottleneck appeared in Sprint 5, because no one had agreed how to fix it.

Problems and Fixes

Moe et al. (2010) studied a team adopting Scrum and found that problems such as low shared leadership and weak team orientation reduced teamwork despite the framework's practices. Desert Sky's team had three problems. Branch managers bypassed the product owner with direct requests to developers; the deputy director now routes all requests to Tanaka. Reviews were becoming demonstrations without discussion; the panel now uses the feature on their own devices. The firm's developers rotated too often; the contract now names a stable team. One problem remains: the district's budget is approved yearly, which sits awkwardly with a backlog that changes every two weeks.

Conclusion

In Sprint 7, Scrum's elements worked as a system: accountabilities made clear who decided what, the sprint goal guided planning, daily inspection exposed a blocked review, the review reshaped the backlog, the retrospective improved the definition of done and the increment reached patrons. Solving the remaining budget mismatch is the next step for the district.

References

Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480-491. https://doi.org/10.1016/j.infsof.2009.11.004

Schwaber, K., & Sutherland, J. (2020). The Scrum guide: The definitive guide to Scrum: The rules of the game. https://scrumguides.org/

Stray, V., Sjøberg, D. I. K., & Dybå, T. (2016). The daily stand-up meeting: A grounded theory study. Journal of Systems and Software, 114, 101-124. https://doi.org/10.1016/j.jss.2016.01.004