SDLC
Introduction#
An agile Software Development Life Cycle (SDLC) defines a team’s workflow — the stages work items pass through from idea to production. These stages are designed to promote the rapid delivery of high-quality software. The scope of each stage is determined by the criteria that a work item must meet to allow it to move to the next stage, known as the Definition of Done, covered separately.
Choosing the right stages is an important foundation for a well-functioning team. The most basic setup consists of three stages — To do, Doing, and Done — but most teams benefit from splitting some of these stages. This page explores the benefits of specific stage splits and offers practical guidance.
Key points
- Define and document the stages of your workflow and the Definition of Done for each.
- The workflow should help you achieve high quality and rapid delivery without compromising either.
- Use WIP limits to improve Lead Time and Cycle Time.
- Hold each other to account to ensure the SDLC is adhered to.
- Aim to shift testing and operational considerations left and automate as much as possible.
- Continuously review the workflow to find ways to reduce waste and improve quality. The process should work for the team and help it deliver faster and better. Where waste is found, eradicate it.
Agile SDLC vs Waterfall SDLC
An agile SDLC defines stages through which each work item must pass. In contrast, a traditional waterfall SDLC defines stages through which the entire project must pass. While the stages may appear similar, the result is very different.
Types of work item
There are four main types of work item: user stories, bugs, technical improvements, and spikes.
In a product delivery team, most work items should be user-centric (user stories or bugs), and this is implicit in much of the discussion here. But not all valuable work is of this type and it is best to be clear about this. The two main other types of item are:
- Technical improvements: Purely internal changes such as refactoring that is too large to fit inside a user story or upgrading components to fix security vulnerabilities.
- Spikes: Exploratory work to understand how best to do something, or whether it is even possible.
Although these do contribute toward creating user value, the connection is too distant to make it feasible to write proper user stories to represent these kinds of work. Instead, these should be written in terms of the risk reduction or opportunity enablement value they hold — terms borrowed from the Weighted Shortest Job First (WSJF) ↗ prioritisation technique.
To do stage#
To do
Doing
Done
Split the To do stage into two substages: Backlog and Ready.
The To do stage contains an ordered list of work items to deliver. These items will have only high-level detail, and will need to be refined to add enough detail to be ready to move into the Doing stages. Items that have been refined are held in the Ready substage until pulled in by the team to be worked on.
Doing stage#
To do
Doing
Done
Split the Doing stage into at least two substages: Implementation and UAT.
This stage is where the artifacts are built and verified. This stage usually involves writing production code, unit tests, and other test code; performing a code review; and some form of user acceptance. For non-coding items, there are equivalent tasks — for example, for an item to update a section of public-facing documentation, this would involve writing the documentation, checking it for spelling and grammar, and peer-reviewing it.
This construction, automated testing, and review should be done together as one stage, not split. This substage is called Implementation.
Don’t split development and testing
The practice of splitting development and testing into separate stages is not recommended as it tends to lead to enlarged batch sizes, less testable code, poorer test coverage, and more waste, through hand-offs and rework.
The term Product Owner is used to represent this and similar roles, such as Product Manager or other stakeholder.
Ideally, implementation will consist of multiple small commits, each containing a small amount of production code and the corresponding automated tests, and will be peer-reviewed before merging. The Product Owner may be involved at this stage to provide input and early validation.
Before moving items to Done, the Product Owner should have a last check to ensure they’re happy for it to go live. This is called User Acceptance Testing (UAT) and is usually performed in a development or test environment. If fundamental issues are discovered at this stage, then the item may need to be moved back to implementation for further work, but small improvements are better handled by creating a new backlog item to represent the enhancement to avoid the item becoming stuck in progress for too long.
To do
Doing
Done
If the team is practicing Continuous Deployment ↗, then changes are automatically deployed to the production system on every code merge. But this is rare and most teams instead practice Continuous Delivery, where changes are automatically deployed to a development environment but require the production deployment to be manually triggered. Items that are ready to deploy but waiting for the next production deployment to be triggered should sit in a new Ready to deploy substage.
Done stage#
To do
Doing
Done
Items in a Done stage should not require further work.
The slice of functionality delivered by the item should be of sufficient quality to not need to be revisited, but other slices may need to be delivered before a threshold is reached where an entire feature is ready for use. So this stage needs no splitting and consists of a single stage, often called Deployed to be specific about what Done means.
WIP limits and metrics#
Limiting work in progress (WIP) improves the flow of work.
Two of the most valuable metrics used to measure the agility of teams are Lead time and Cycle time.
Lead time: The combined time spent in To do and Doing, sometimes known as the time “from idea to production.”
Cycle time: Time spent in the Doing stage, a good measure of team delivery effectiveness.
Shorter lead time and cycle times show that the team can respond quickly to changing priorities, an important indicator of agility that has real business value.
An effective way to improve the flow of work, and especially the cycle time, is to restrict work in progress (WIP) — the number of items actively being worked on at any time. Agile delivery software such as Jira supports automated WIP limits that either prevent items from being moved a stage that has already hit its WIP limit or at least provide a warning to draw this to the team’s attention.
All teams are recommended to set strong WIP limits and stick to them. This forces impediments to be challenged and improves the flow of work.
Blockers#
Indicate blocked items with flags or tags, not using a separate column.
Although part of the purpose of refinement is to identify unknowns that would cause an item to stall during delivery, impediments do sometimes still occur that cause an item to become blocked — unable to proceed until something else has been done. This could be something required from outside the team or could be due to dependencies between items.
Blocked items should be indicated with a status flag, tag, or similar. A common anti-pattern is to instead use a blocked column and this is not recommended as it loses information about the stage in which an item has become blocked. Blocked items should still count against their state’s WIP limit, which encourages impediments to be resolved quickly.
Up-front vs just-in-time#
To do
Doing
Done
Delay detailed design work to just in time.
Items in the Ready stage are ready to bring into the Doing stages. But the amount of detail required at this point varies, depending on the team’s ways of working.
Teams working in the strongly iteration-based style typical of Scrum will aim to have worked out and documented all the details up-front needed to be ready to move directly into Implementation and start writing code.
Scrum and Sprint Planning
Scrum places a strong emphasis on selecting a set of work items to complete within the upcoming sprint and minimising changes to this scope during the sprint. This is done during Sprint Planning ↗, where items from the backlog are refined from the backlog until they are ready for implementation.
Those working in a continuous flow Kanban style will favour deferring some of this detail to just before implementation begins. This just-in-time enrichment of the item description is represented by introducing a new Elaboration substage.
There are several benefits to this just-in-time approach:
| Just-in-time | Up-front |
|---|---|
| More information is available. Designs take account of everything known just before implementation. Estimates are most accurate. | Less information is available. Designs may be sub-optimal as they are uninformed by information that came to light between refinement and implementation. Similarly, estimates are less accurate. |
| The chance of waste is reduced as less effort has been expended elaborating items that may end up not being implemented. | Sometimes priorities change and items that have undergone detailed design work may be discarded, leading to wasted effort. |
| The context is fresh, especially if elaboration is done by the person or pair who will move straight into implementation. | Since detailed elaboration and implementation are done at quite different times, and likely by different people, the chance of misunderstanding is increased, as with any hand-off. |
| If elaboration is done by the people who will move straight on to implementing the item, elaboration may not be done as rigorously, not all details may be documented and therefore potential issues may not be uncovered. Deliberate attention is required to avoid this. | Deliberately separating elaboration and implementation can encourage better discipline and higher quality results. |
The main hurdle to moving to true just-in-time elaboration is that the required people may not always be available. People who are not full-time members of the team may be busy doing other things, meaning items get stuck or elaboration proceeds without their input, increasing the risk that the wrong thing will be built. In practice, it is fairly common for critical roles such as the Product Owner, tester, or certain SMEs to have responsibilities outside the team, and this can mean that elaboration needs to be done a little in advance of implementation. It can work well to schedule elaboration sessions for when people are available and deliberately keep a small number of elaborated items ready to implement. In this scenario, the time elapsed between elaboration and implementation is still typically much shorter than if all detail is worked out in an up-front refinement process, so most of the benefits still hold.
Wait stages#
To do
Doing
Done
Wait stages are useful as holding areas and to identify waste.
For most stages, work is needed to move items into that stage. For example, to move from Backlog to Ready, refinement is needed as detailed in the associated definition of done. But the Ready and Deployed stages we have already identified are in fact “wait stages” — holding areas for items that have completed the previous stage and are ready to move into the next — or in the case of the Deployed stage, where there is nothing left to do.
It can add clarity to introduce additional wait stages between work stages. The primary candidate for this is to add a Ready for implementation stage between Elaboration and Implementation, which is useful if the team is deliberately maintaining a buffer of elaborated items (see Up-front vs just-in-time). This additional stage makes it clear which items are actively being elaborated and which have completed elaboration.
It can also be useful to add wait stages where hand-offs occur to track wait time, such as between Implementation and UAT. This should be done sparingly as it complicates the workflow, but it can help identify and resolve wasteful delays.
Closing remarks#
Each stage is described in more detail in Definition of Done.
Tips
- Give your team’s workflow careful thought and craft it to ensure all the right steps are done in the right order, with minimum overhead, wait time, and hand-offs.
- If your current workflow is not how you’d like it to be, start by writing down the current process. This gives you a concrete starting point from which to iterate.
- Although agile process is important, team culture plays and even bigger part in determining success. Good process is useless if there is a toxic culture, whereas the right culture will quickly lead to process issues being identified and resolved.
Mistakes to avoid
- Don’t overcomplicate your workflow — keep it as simple as possible to give you the structure you need.
- Your workflow should align with reality. If there is a hand-off between roles, this should usually be represented with two different stages. This shines a light on what’s really happening and helps identify how things can be improved.
- Be clear on the different types of work item (user story, tech improvement, exploration), and always aim for user stories to represent vertical slices of functionality.