LSD CSI Sprint 2 Risks

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
indytechcook's picture

Risks for Sprint 2 - Risks and Plans

Risk 1: Goal clarity - The high-level schedule states "Build plugins, build modules" but the main goal of this sprint is to finish the core SPS system.

Plan: We originally had some tasks associated with this sprint that didn't directly fall under that goal, so we moved to Sprint 3 and brought some clarity to our current effort. Also defining the goal of Sprint 3 in advance i.e. this week, before next Monday, Sprint 3 kick off.

Risk 2: Ticketing - The project needed some better ticket management and perhaps a new system for tracking tickets especially with regard to estimates so we can accurately gauge velocity of the project throughout the sprints.

Plan: I've completed Sprint 2 reporting and start owning the ticking process, workflow and reporting on task completion and hopefully that alone will expedite things. Also we'll discuss and decide on alternative methods for tracking tickets that will improve LOE tracking and expedite reporting on project/sprint velocity.

Risk 3: Overloaded/Resourcing - There were initially too many tickets allocated to Sprint 2. It's hard to be precise on the overage because the ticketing queue on drupal.org issues doesn't seem to have estimates attached.

Plan: After clarifying the goal of Sprint 2 we were able to move some issues outside of it's parameters to Sprint 3, correcting the overload. We also added another developer, Brad Blake, on project starting the week of July 23.

Risk 4: On-boarding New Developers - We have added two new developers in two weeks. While this will decrease velocity initially while we bring them up to speed, it will increase project velocity down the line in coming weeks. Some current work is heavily dependent on other developers efforts so we will need to build in time for developers old and new to plan/execute in conjunction, at least initially.

Plan: I'm considering pairing off some of the developers together in the AM for a couple of hours, a couple of days this week and next. Hopefully this will expedite on-boarding. This of course would also mean Neil would need to be available to help lead developers as they collaborate and work out their integration points.

Risk 5: Preview bar -- An integration point that is sort of unclear for our developers currently.

Plan: filling out the requirements surrounding this beyond the picture we're currently working off of would be helpful. I am going to look over the user stories and try to get an epic to go along with the picture that they have of what the preview bar looks like so assumptions about process will be more clear/documented.