What is Agile Development?
In the context of software development, ‘agile’ is an iterative (phased) approach that helps teams deliver value to their clients faster and with less headaches. While there are a variety of tools out there to support agile management of a project, one of my favorite summaries from Atlassian says, “Instead of betting everything on a ‘big bang’ [approach], an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.”
Common Challenges in Agile Development
A common problem that I have seen Agile teams grapple with is writing user stories and acceptance criteria for projects that are heavy on technical implementation and modifications with no substantive change in the user interfaces or workflows. This kind of scenario is very common in companies that are upgrading an infrastructure or changing an underlying design and architecture to improve performance or scale. These types of projects are typically referred to as ‘IT Driven Initiatives‘ to distinguish them from projects done in response to some specific functionality requested by the Business team.
The User Stories written from the viewpoint of the functionality that users will need does not really provide context in terms of the work to be done by the development team. In most cases, the existing functionality will satisfy the needs of the user with no additional changes needed. The changes are taking place under the hood, as it were. Teams in these situations create user stories that are nothing more than technical implementation details.
It is Common to See User Stories Like This...
“As SYSTEM A, I want to map the incoming Order XML to the main Canonical, so that SYSTEM B can consume the Canonical and run order validation rules against it.”
The acceptance criteria that are provided for a story like this will be filled with technical details on the Order XML, Canonical, validation rules and so on that need to be delivered.
The problems with this approach are readily obvious. There is really no context of what functionality is to be delivered from a user perspective or the expected outcomes from their viewpoint. An entire backlog filled with stories like this can easily become incomprehensible, especially in complex environments. Very soon, developers have no context of what they are building and most importantly, how it is going to eventually be used from a user perspective.
Enter, Technical Stories
At ArgonDigital, we recommend using Technical Stories instead of User Stories in these situations. Technical Stories are best used in conjunction with User Stories to help paint a clear picture. The User Stories provide context to the associated Technical Stories so that the developers understand the functionality from the user viewpoint.
Continuing with the example above, let’s look at how it can be reformulated as a User Story / Technical Story combination, as follows:
User Story
“As an online shopper at ACME Widget Company, I want to ensure that my order is complete and valid when I submit it at the online store, so that I can get the products I ordered in a timely manner without mistakes or delays.”
Technical Story
“In Order to ensure that only valid orders are accepted by the system, System A must map the Order XML to the main canonical and provide the main canonical to SYSTEM B to run order validation rules.”
In a real world scenario, there will typically be multiple Technical Stories needed to deliver the functionality required by the User Story. Technical Stories can be as granular and detailed as needed to ensure that the proper functionality is built. However, they should all tie back to one user story that the developer can quickly lookup to get context on why they are performing the tasks they are engaged in.
How User Stories and Technical Stories Clarify Objectives
I typically tend to write the User Stories in these situations at a higher level or even use Epics, when appropriate. The supporting Technical Stories are written for the team that will work on specific pieces of implementation, or specific sub-systems. Acceptance Criteria are then written to be appropriate for the context of the story – User or Technical.
For example, Acceptance Criteria for the User Story could be along these lines:
AC 1 – User must get a message if the order is valid that it has been accepted for processing.
AC 2 – User must get an error message if the order is invalid with prompts on the issues that must be fixed before it is accepted for processing.
And so on…
Similarly, Acceptance Criteria for the Technical Stories can be written appropriate to their context. For example…
AC 1 – The data from the Order XML must be mapped into the main canonical in accordance with the mapping shown in the attached spreadsheet.
AC 2 – Main canonical must be passed to SYSTEM B via interface A using API K and a success message received when the transfer is complete without errors.
And so on…
The Benefit of Creating Both User Stories and Technical Stories
When the stories are split out like this, it becomes very easy to test the delivered functionality. Continuing with our example above, simple regression tests can be written for the User Stories to ensure that the end user experience is consistent with current state behavior. Tests created for the Technical Stories will be qualitatively different and focused on functionality at a much lower level.
Agile Development Takeaways
- Keep User Stories focused on the user experience and outcomes.
- Write Technical Stories to give context to the User Stories from a system perspective.
- Map Technical Stories to User Stories so that it is clear how the functionality being developed relates to the user experience.
- This technique is very effective for projects where the user experience or user interface does not change but the underlying technical infrastructure is being changed to improve performance, upgrade technology or other technical reasons.
Need Help With a Project?
We offer a variety of services to help you with your technology updates and/or implementations. Whether you need help creating a technology roadmap, software selection, or you simply would like to train your teams up on their requirements skills, we can help!
