MGMT 651 Week 6 DB Forum 6 Example

Discussion Board Forum 6: Thread and Two Replies

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

Thread by [Student Name]

The prompt, the parks department's project and the classmates' posts are composites standing in for the course's own forum; Gido and colleagues' textbook, the published studies and Scripture are real; the requirements follow Liberty's public course guide for MGMT 651.

Thread

Our state parks department runs an online reservation system for 4,800 campsites and 300 cabins across 42 parks, and the system, built in 2009, crashes every January when reservations open for the summer. Last fall the department hired a development team to rebuild it, and the governor's office announced that the new system would open on March 1, the first day of the reservation season. The team had not yet estimated a single feature.

The team began by estimating the backlog with planning poker. Developers, two park reservation managers and a product owner from the department met for three sessions, estimated 96 user stories in story points and arrived at a first total of 372 points. Moløkken-Østvold et al. (2008), studying planning poker in a software company, found that estimates reached through group discussion were less optimistic and more accurate than statistical combinations of individual estimates for the same tasks, partly because discussion surfaced work that individuals had missed. Our sessions did exactly that: the reservation managers pointed out that refunds for weather closures needed their own stories, which added 38 points and brought the backlog to 410. Jørgensen (2004), reviewing studies of expert estimation in software development, concluded that expert judgment is widely used and can be as accurate as formal models, provided that estimators combine views and guard against wishful thinking.

After three two-week sprints, the team had completed 36, 43 and 38 points, an average velocity of 39. Cohn (2006) describes velocity as the basis for release planning: dividing the remaining backlog by velocity gives a forecast in sprints. With 410 points and a velocity of 39, the full system would take about 10.5 sprints, or five months, and the range from the slowest to the fastest sprint ran from 9.5 to 11.4 sprints. Even the optimistic end missed March 1 by more than two months. Gido et al. (2018) treat the schedule as a plan built from estimates of the work, and our estimates said the date could not hold for the full scope.

The product owner and the team proposed a minimum viable release for March 1: searching, booking and paying for campsites, about 190 points, with cabins, group sites and the refund workflow to follow in May. Leadership accepted it, and the March launch handled 61,000 reservations in its first week without an outage.

In Luke, Jesus describes a would-be tower builder who works out the expense before laying the foundation, so that the building is not left half done (English Standard Version Bible, 2001/2016, Luke 14:28). Honest estimating is counting the cost aloud, especially when the answer is not the one leaders want to hear.

Classmates: has a date on your project ever been set before the work was estimated, and what did your team do?

Reply to Erica

Erica, your thread on the patient portal redesign at your clinic network described a team that estimated 300 story points and committed to finishing in six sprints because leadership wanted a summer launch. You also mentioned that the team's first two sprints completed 31 and 35 points, and that two developers are shared with another project.

Cohn (2006) recommends forecasting from measured velocity rather than desired dates. At an average of 33 points, 300 points would take about nine sprints, not six, so the summer launch is at risk on the team's own numbers. Moløkken-Østvold et al. (2008) found that group estimation through planning poker reduced optimism, but optimism can return when a team commits to a date rather than forecasting one. Your sprint review is a natural moment to raise it. Showing leadership a range, roughly eight to ten sprints based on your slowest and fastest sprints so far, might open a conversation about releasing the most valuable features first.

A forecast range is not a refusal; it is information leaders need to choose between scope and date with their eyes open. Which features would patients miss most if the summer release included only half of the backlog?

Reply to Darnell

Darnell, your thread described your logistics company's plan to double the size of a late agile team, from five developers to ten, to recover a delivery date for a routing app.

Adding people may not speed the team up in the short run. New members need to learn the codebase and the team's working agreements, and experienced members slow down while they help. Jørgensen (2004) emphasizes that estimates should account for the realities of the people doing the work, and a team's velocity reflects its current members and their familiarity with each other. Gido et al. (2018) describe resource changes as having effects on the schedule beyond the simple addition of hours. A larger team may also need to split into two teams, which brings coordination costs.

An alternative would be to keep the team intact, measure its velocity for one more sprint and reduce the scope of the first release. If additional developers are necessary, adding them early in a new release, rather than near the deadline, gives them time to become productive. It would also help to ask the drivers and dispatchers which routing features they need first. How many sprints remain before the date your leadership has set?

References

Cohn, M. (2006). Agile estimating and planning. Prentice Hall.

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

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

Jørgensen, M. (2004). A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1-2), 37-60. https://doi.org/10.1016/S0164-1212(02)00156-5

Moløkken-Østvold, K., Haugen, N. C., & Benestad, H. C. (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106-2117. https://doi.org/10.1016/j.jss.2008.03.058