#
Scrum at MidFirst
#
1. Epics and user stories are created by Product Owner (PO)
Product owner creates the epics (milestones) and the user stories that are contained within them. Epics represent much larger collections of features while user stories describe individual tasks that a user can accomplish while using the application.
A well-defined backlog is crucial to team success when building a product. Over the course of the development cycle, the backlog is consistently refined by the team and used to inform planning and discussion. It is acceptable to have a backlog that does not contain every feature that will be built in the application. However, it is recommended to always have at least a couple sprints worth of backlog items created before the start of any refinement session so that the team has enough stories to build the upcoming sprint.
#
2. Backlog creation, organization, and prioritization by Product Manager (PM)
A "sprint bucket" is created by the product manager (PM). This bucket contains all of the user stories that the PM would like to accomplish in the given sprint. The scrum team will later determine if they are willing to commit to accomplishing all of these stories within the sprint and may reject some stories based on that determination.
PM will prioritize tasks as he/she finds appropriate. This prioritization may not always be the order in which the scrum team works tasks associated with this user story. Oftentimes, there are reasons that a story or individual tasks cannot be worked on right now and the team tries to remain productive while also considering the priorities established by the PM.
Other backlog items may be pulled into a sprint bucket to account for blockers or excessive capacity. The goal is to accomplish as much work as possible and keep implementation teams moving over the course of a given sprint and sometimes adjustments to the plan need to be made mid-sprint.
A sprint should be organized according to priorities established by the PM but also account for inter-sprint dependencies. For example, if a user story contains a feature that requires the building of a common, reusable UI component before the actual UI feature can be built then a dependency on the common component has been established and the work on the actual UI feature cannot begin until the dependency is resolved. In this example, the common component must be built first and the sprint organization should reflect that dependency.
It is very important that dependencies such as this one are identified as early as possible in the planning process.
It is preferable that these dependencies are spread across sprints. A sprint that contains a cascade of dependencies is at a high risk of not being completed on time. If a sprint is scheduled for 2 weeks and a particular user story has 3 cascading dependencies, the final task to complete the feature may not begin until the sprint is almost over. !!!
#
3. Ceremonies scheduled by Scrum Master (SM)
The scrum master (SM) is responsible for establishing the sprint cadence and scheduling all ceremonies for a sprint. These ceremonies include the following:
- Backlog refinement
- Sprint planning
- Daily standup
- Sprint demo
- Sprint retro
#
4. Backlog refinement
Backlog refinement is the process by which the team reviews user stories, discusses the technical considerations for accomplishing features, and attempts to define any individual tasks that need to be created. In this meeting, inter-sprint dependencies should be identified, called out, and documented. This helps PM to understand which stories might have a higher level of risk and gives PM the opportunity to limit that risk by splitting stories/tasks across sprints.
As stories are refined by the team, story points should be assigned to each story (or task depending on team preference)
This meeting should be held at regular intervals, once per week recommended but not always adequate.
#
5. Sprint planning
Between the end of the last backlog refinement and the start of sprint planning, the PM should attempt to organize the upcoming sprint bucket based on established priorities, average sprint velocity, and consideration of dependencies identified by the scrum team in refinement.
The sprint planning meeting gives the team the opportunity to commit to or reject stories from the sprint bucket based on team capacity, velocity, or other criteria. This should be a final review of the sprint and is the last meeting before the sprint begins.
#
6. Daily standup
Standup is a daily meeting, typically first thing in the morning or any consistent daily time, in which the team communicates and calls out potential problems and blockers. This meeting should not be a review of all tickets on the board with the expectation of status updates.
Blockers represent an elevated risk that a sprint commitment may be missed and should be addressed as quickly as possible by the scrum master, tech leads, or other team members as necessary. It is common for unforeseen blockers to come up during a sprint. These blockers can cause work to be put on hold and can result in backlog tickets being pulled into a sprint to fill excess capacity.
#
7. Sprint demonstration (Demo)
The end of each sprint should include a demo of the collective work accomplished during the sprint. The demo provides an opportunity for developers to showcase their work and for stakeholders to review progress in order to provide feedback, course corrections, and inform decisions.
Any features/fixes that were not merged by end of sprint should not be included in the demo and their tickets should be carried over into the next sprint.
#
8. Sprint retrospective (Retro)
Our agile process is very organic. It allows for teams to make quick course corrections and rapid improvements not only to products but also (especially) to the process itself. The sprint retrospective is an extremely important feedback mechanism that facilitates these improvements.
Retro should be conducted at some point (usually immediately) following the demo. Retro is attended only by the scrum team and scrum master and is intended to be an internal team reflection on how effectively the sprint was executed as well an opportunity for the team to suggest and implement changes that will make the agile process more effective.
In order to have the most effective retrospectives and, thus, the most efficient scrum teams, it is vitally important that retrospectives be a private, safe place for the team to offer honest feedback and constructive criticism on their execution of the sprint itself. In order to defend this privacy and enable effective communication of difficult or contentious topics, some team members may elect to submit feedback to the scrum master ahead of retro in private so that it can be distributed to the team anonymously.
Because of the organic nature of agile and the self-reflection and improvement mechanism of retrospective, separate
agile teams will naturally tend to take on variances from one another over time. This is perfectly normal and acceptable. Each team is made of different members that work together more effectively in different ways. We provide a framework for identifying the most efficient team dynamics and implementing them. For these reasons, it is not acceptable to compare one agile team to another in terms of velocity, story/task structure, and most other metrics. !!!
#
9. Close of sprint tasks
The conclusion of each sprint is the point at which code accepted during the sprint is merged and deployed to various environments (qa/review/prod) and the cycle begins again. Tech leads finalize the process of merging release candidates, generating new application versions and release notes (automated), and setting up future deployments. Once release candidates are merged the process of merging any code held up in review or code freezes from the previous sprint can begin.
#
Other considerations
#
External dependencies (DevOps, InfoSec, Vendors etc)
Oftentimes, there will be dependencies within a sprint (or across multiple sprints) that the team does not have control over. These dependencies could be vendors, other departments, or any externality that could potentially affect the successful execution of any given story/task. We typically create a ticket on the board that serves as a call-out of this dependency. That ticket is then assigned to someone on the team who is responsible for getting status updates from the party actually responsible for it.
These tracking tickets represent risk and we should attempt to structure our sprints in ways that limit the potentially negative impact if the external party is unable to fulfill the dependency according to our expectations.
#
Code freezes
Many of our projects have manual QA testers or QA automation engineers assigned to them. They are responsible for validating stories/tasks have been implemented according to the AC defined on the ticket. The nature of this verification work naturally requires that their validation process cannot begin until dev work for any given task has been completed, code reviewed, and deployed to some environment for testing.
Some teams have taken an approach that budgets time into the process for the QA team to catch up to the dev team at the tail end of the sprint. This means implementing a freeze on new code being merged into the release in the days leading up to the sprint end date.
Example: Sprint is scheduled to run 13 business days (Monday to the Wednesday 2 weeks following). Code freeze goes into effect on business day 10 of the sprint (second Friday). This gives the QA team 3 days to perform testing of any features/fixes delivered as of end of day Friday.
Implementing the code freeze does not mean that development work must stop completely. Progress can continue to be made on open tickets as long as the code is not being merged into the release during the code freeze period.
#
Sprinting a marathon creates burnout
Most products cannot be built in just a few sprints. Stacking every sprint to begin at the immediate conclusion of the sprint that came before it can easily foster burnout within the team and lead to reduced productivity or loss of team members in the medium to long term. A small amount of pressure at the right time can give increased focus and motivation. A large amount of consistent, unrelenting pressure to deliver creates burnout and leads to other unwanted negative outcomes. We have found that a few days between the conclusion of one sprint and the commencement of the next provides a healthy balance between these two states. It allows for additional planning and reflection time and also gives team members an opportunity to catch up on non-sprint-related work such as maintenance, corporate trainings, or other tasks that were neglected during the course of the previous sprint.
#
Demo documents
Before the demo, the SM (or any team member) may provide the team with a document that outlines all of the tickets that have been accepted as a part of this sprint.
This document should outline each individual story to be demonstrated as well as the person responsible for demonstrating it (tasks may optionally be included). Most teams elect for the developer responsible for implementation to be the person that performs the demo it but this is not required and not, necessarily, always the case.