Managing Scrum & Software Development Sprints

The Scrum methodology illustrates a workflow for the flow of User Stories through each Sprint with three workflow steps: To Do, In Progress and Done.

To do are items not yet started by the Team. In progress are items the Team have started but that do not yet meet the definition of done (acceptance criteria) for the Story or the release (or both). Done items are those Stories that meet the definition of done for both the Story and release.

The Scrum Team at CodeStringers includes two broad categories of personnel: software developers and quality assurance engineers. Architects, database engineers and others would be in the software developer category.

As such, it’s helpful for the Sprint Workflow to illustrate where each User Story is in terms of the definition of done.

As a result, CodeStringers uses a five-step workflow for Sprints. Our steps (also referred to as “columns” because they are typically visualized on a physical or web-based “board” as columns) are as follows (and illustrated above):

This column includes all items not yet started, just as prescribed by the Scrum method.

This column includes User Stories that failed to meet either or both the Story and/or release definition of done, so the quality assurance engineer who tested the software.

This column includes User Stories that the software developer pulled from “To Do” and began developing, but has not yet finished developing.

This column includes User Stories that the software developer believes are “done” that he wants the quality assurance engineer to test against the defined test cases, which are created from the Story and release acceptance criteria.

This column includes User Stories that the quality assurance engineer confirms meet the Story and release acceptance criteria and thus are in fact “done”.

For all cloud-based software products CodeStringers builds, we maintain three distinct and identical hosting environments.

The development environment, as the name suggests, is where developers are coding features. This environment is changing continuously as developers change code and deploy it for smoke and/or unit testing.

The rate of change in this environment is such that it’s implausible to complete quality assurance testing in the environment because the changes may introduce defects that impact the features quality assurance is testing but that aren’t in the code they are testing.

When developers believe their work meets the definition of done, they release the code to the staging environment.

The staging environment is where the quality assurance team completes their testing. This environment is named “staging” because it’s where code is “staged” for production release. The staging environment is, ideally, identical to the production environment. In reality, though, staging often lacks the amount that exists in production creating a risk that load testing in staging does not yield accurate results.

The production environment is where real users engage with the software. Changes to this environment, whether it be the deployment of new or changed code or changes to the hosting environment configuration, must be carefully controlled. The goal of any production operations team is 100 percent availability of the software (except for planned maintenance windows). While that goal is rarely achieved, change control ensures the highest possible availability.

As such, the release of code from staging to production happens only when quality assurance and operations have reviewed testing results and other factors that might impact availability or performance, and approved the release.

Following every production release, the quality assurance team completes smoke testing (light testing of features that attempts to mimic the behavior of real users) is completed to ensure that any variations between staging and production have not introduced “environmental” defects (those related to the scale or configuration of a given environment).