MGMT 651 Week 3 DB Forum 3 Example

Discussion Board Forum 3: Thread and Two Replies

MGMT 651 Agile Project Management, Discussion Board Forum 3 (thread and two replies)

Thread by [Student Name]

The prompt, the utility's portal and the classmates' posts are composites standing in for the course's own forum; Gido and colleagues' textbook, the Scrum Guide, the published works and Scripture are real; the requirements follow Liberty's public course guide for MGMT 651.

Thread

Our city's water utility serves about 46,000 accounts, and for years customers asked for two things: a way to pay bills online without calling, and an alert when their meter showed a possible leak. In 2023 a consultant delivered a 140-page requirements specification for a portal that would do both. It described every screen, field and error message. A year later, nothing had been built. The vendors who bid found the document impossible to price, and when our customer service staff finally read it, they found that it assumed customers would know their account numbers, which most do not.

Last year the project restarted with an agile approach. The new product owner, the customer service manager, and the development team rewrote the requirements as 62 user stories, each written from a customer's point of view, such as: "As a homeowner, I want a text when my meter shows continuous use for 24 hours, so that I can find a leak before my bill doubles." Each story carried acceptance criteria, for that one including that the text names the address and the hours of continuous use. Cohn (2004) describes user stories as short descriptions of functionality valued by a user, meant as placeholders for conversation rather than full specifications, and his INVEST criteria, independent, negotiable, valuable, estimable, small and testable, helped us split oversized stories.

The Scrum Guide treats the product backlog as a living, ranked inventory of the work the product still needs, and makes the product owner answerable for it (Schwaber & Sutherland, 2020). Our product owner ordered the stories by value to customers and by risk, putting leak alerts first because a single undetected leak had cost one family $1,900 the year before. Gido et al. (2018) emphasize defining the project's scope and deliverables so that work can be planned and tracked, and the ordered backlog became our scope, revisited every sprint.

The approach has a known weakness. Reviewing the published work on how agile teams handle requirements, Inayat et al. (2015) identified challenges that included customer availability, minimal documentation and the neglect of nonfunctional requirements such as security and performance. Our first stories said nothing about protecting payment data or handling 46,000 customers paying on the same due date. We added nonfunctional stories and a definition of done that required a security review for every payment feature.

Habakkuk was told to write the vision and make it plain on tablets, so that a herald could run with it (English Standard Version Bible, 2001/2016, Habakkuk 2:2). A good user story is a small vision made plain enough that a developer can run with it.

Classmates: how does your organization write requirements, and who decides which come first?

Reply to Nicole

Nicole, your thread on the discharge instructions app at your hospital described a requirement that read, "The system shall provide discharge information to patients." I agree with your sense that it was too vague to build from.

Cohn (2004) suggests writing such requirements as user stories that name the user, the goal and the benefit. Yours might become: "As a patient going home after heart surgery, I want my medication schedule in plain language on my phone, so that I take the right doses at the right times." Acceptance criteria could require a reading level no higher than sixth grade and a confirmation from the discharging nurse. Inayat et al. (2015) note that customer involvement is central to agile requirements and that its absence is a common challenge, so including two former patients in your backlog refinement sessions would strengthen the stories. Their questions after discharge, such as what to do when a dose is missed, would probably produce stories the clinical team has not thought of.

Gido et al. (2018) stress agreeing on what the customer actually needs before planning the work, and a patient-written story is the most direct form of that agreement. Has your team spoken with patients about which discharge information they struggle with most once they are home?

Reply to Marcus

Marcus, your thread about moving your school district's paper enrollment packet online listed thirty requirements gathered from principals, the registrar and parents, but you were unsure where to start.

The Scrum Guide gives the product owner accountability for ordering the backlog to maximize value (Schwaber & Sutherland, 2020), so your first step may be to name one person who can make those calls. Value might mean the stories that remove the most work for families: uploading proof of residence from a phone, or prefilling returning students' information. Serrador and Pinto (2015), studying projects across industries, found that agile use was associated with stakeholder satisfaction, and early releases of the features parents care most about, delivered before the August enrollment rush, are one reason why.

Some requirements, such as student records retention rules, will need to come first regardless of value because the law requires them. Gido et al. (2018) describe identifying constraints during planning, and those belong at the top of the backlog. Once the product owner is named, a short session ranking the thirty requirements with the registrar and two parents would give the team its first two sprints. Who in your district has the authority to act as product owner for this project?

References

Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley.

English Standard Version Bible. (2016). Crossway. (Original work published 2001)

Gido, J., Clements, J., & Baker, R. (2018). Successful project management (7th ed.). Cengage Learning.

Inayat, I., Salim, S. S., Marczak, S., Daneva, M., & Shamshirband, S. (2015). A systematic literature review on agile requirements engineering practices and challenges. Computers in Human Behavior, 51, 915-929. https://doi.org/10.1016/j.chb.2014.10.046

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

Serrador, P., & Pinto, J. K. (2015). Does agile work? A quantitative analysis of agile project success. International Journal of Project Management, 33(5), 1040-1051. https://doi.org/10.1016/j.ijproman.2015.01.006