- Technology: Azure DevOps
- Sphere: Development
- SDLC: Development
- Cadence: Bi - weekly
Moving forward we are going to be entering work into the sprint with the developer assigned to the "User Story" level, which we will call the "Blue" level for the remainder of this document.
That includes:
- User Story
- Bugs
- Change Requests
Rules:
- Developers are assigned to Blue Levels.
- Each Blue Level has a single developer assigned to it.
- Story points are equal to the Original Estimate on the Task.
- Each Blue Level is able to be completed in a single sprint.
- We are devoted to closing as many Blue Levels per sprint.
¶ Each Blue Level has a single developer assigned to it.
With the Developer assigned to the Blue Level, we must have a single developer per Blue Level.
For Instance:
This User Story, "Orders", has the following Estimation
If there is an instance where a Blue Level requires both Front End and Back End work, we must break out the Blue Level to multiple Blue Levels.
This User Story will require back-end work related to the dynamic displays of the Patient's First/Last Name. However, it does not preclude the front-end developer from beginning this work.
The Front-End User Story could be titled: "Orders: Grid and UI", this would have 6 Story Points.
The Back-End User Story could be titled: "Orders Grid: Dynamic Results", this would have 2 Story Points.
¶ A Blue Level must have its story points match the total of time on the task.
At the end of the sprint, we will be determining the total amount of Completed Blue Levels in the sprint. This includes tasks that have been Deployed to QA, Passed QA, or Closed. We will require all Blue Levels to have their states updated on the Tuesday before the sprint.
¶ The goals for this are the following:
- With the specific developer assigned to the Blue Level, any bugs or QA Failures that happen with that Blue Level can return directly to that developer.
- With the Blue Levels broken out between Back End and Front End work, we can more easily track dependencies between the two, and plan work with hopefully fewer blocks.
- We can more accurately track the completion of Blue Levels, which can help update the State of the Blue Level.
- Ultimately we are more concerned with the completion of development rather than time
- Showing a client completed work, is much better than showing a client progress
Related Articles
Sprint Planning Best Practices