Any suggestions to better the system's schedule estimation and implementation methodology for the project below?

Project Discussion

Not really sure what else to add or discuss about my project that I haven't touched on last week or the week before. If anyone has specific questions, feel free to ask. However, my project is a rock climbing / bouldering focused mobile application. Its main intent is to help climbers find partners to lead rope and top rope indoors and outdoors. It will also double as a climbing social media hub for the local climbing scene by helping users coordinate outdoor adventures or indoor activities. Being in the military I am forced to move quite often. This always means I must remake friends and relearn where the fun places to climb are. Hopefully, this app can reduce the time it takes to get integrated into the local culture and get going onsome great routes/projects.

Implementation Methodology

The provided reading for this week's assignment touches directly on my experience and mind set when tackling scheduling andproject planning in general. Herroelen (2005) states right in the abstract "The vast majority of the research efforts in project scheduling assume complete information about the scheduling problem to be solved and a static deterministic environment within which the pre-computed baseline schedule will be executed. However, in the real world, project activities are subject to considerable uncertainty, which is gradually resolved during project execution." This is the exact reasoning why when done correctly Agile can be beneficial. (Herroelen, para 1)

This project will focus on utilizing best case and worst-case scheduling boundaries with the goal of the project being completed in between these boundary dates. These dates should be coordinated with upper management and all stakeholders to understand their risk tolerance and their need by dates. A 100% solution completed when it is no longer needed is worse than an 80% solution completed ahead of time. Program management is all about managing expectations, making give and take decisions, and then conveying these realizations to stakeholders about why we can't have it all.

Belay Buddy's team will sync around a two-week sprint cycle. Sprints are the main method for completing work on this project. During sprints requirements are split into more manageable sub-tasks that can ideally be completed in two weeks or less. After a sprint, a demonstration of what the team accomplished is presented. The team then discusses what went well and what can be improved. The team then decides what tasks from the back log will be worked on during the next sprint cycle. The team can add new items to the back log or re-prioritize items depending on what was learned from the demo and current priorities. Risk mitigation is a key factor in this process as it can help influence what is needed to be worked on and what can wait. Quick reaction to risks and unexpected situations is why i have enjoyed using these methodologies in the past.

The back log is the key method which allows an Agile process to work as intended. When the team maintains the back log, they will attempt to sub-divide larger tasks so they can be completed within a sprint cycle. Some Agile teams use story points to help define how much work is associated with a task. Belay Buddy will not be using story points, but an associated time estimate that will be given to each task.

Important Metrics

The biggest questions any team and manager will have are "how do we know if we are on track" and "when can we expect to complete our project." Using sprints and the Jira software this information can be available right at the team's fingertips. The best metric to use is the back log. Tracking the growth stagnation, or reduction is a good data point in tracking how the project is progressing. It is normal for the back log to not change or grow during the first several sprint cycles. This is normally due to all the unknown - unknown factors being discovered and team members breaking down larger tasks into more manageable pieces.

Once this growth phase has subsided, the backlog should start to shrink as tasks are completed and sprint demos shown. This burn down rate is the key data for how long the project will take to complete. Jira is constantly analyzing each sprint the team completes and can use the associated story points or time value for each task to give estimated amount of work left and expected sprints remaining. The project manager can use this data to help keep the team on schedule by working with upper management to provide the team with any extra resources they may need. The project manager may de-prioritize some requirements to keep the larger project on schedule for release then add those items later.

Major Events

• Every two weeks - Sprint Planning and Retrospective
• Every two weeks - Sprint Demo
• Month 4 - Live Server Test-Low Bandwidth
• Month 5 - Live Server Test-High Bandwidth
• Month 6 - Initial Public Release