Skip to main content

Technical User Stories – What, When, and How?

Written by Robert Galen on . Posted in Articles.

georgep Nov27It happens to me on a weekly basis. I’m teaching a class on how to write User Stories. Usually it’s part of my Product Owner workshop. We’re happily writing stories for an iPad application simulation. Typically halfway thru the exercise someone raises their hand because they’re struggling with the format of a purely technical story. Quite often they don’t know how to frame the “user” clause and are stuck there in their writing.
My first recommendation is often to tell them to skip it. I tell them that the “As a” and the “So that” clauses are usually quite different for technically related stories. I just ask them to quantify the need (technically), in clear English with perhaps a couple of sentences, and then move on.

In fact, I ask them to spend more time on the confirmation or acceptance part of the story, because I find that this is an area that needs “development” for more technical stories. Usually they’re still frustrated because they want to write “good” stories, but they reluctantly move on. But I’m getting ahead of myself a bit. Let’s focus first on a simple definition for Technical User Stories so that we’re all on the same page.

Technical User Stories Defined

A Technical User Story is one focused on non-functional support of a system. For example, implementing back-end tables to support a new function, or extending an existing service layer. Sometimes they are focused on classic non-functional stories, for example: security, performance, or scalability related.

Another type of technical story focuses more towards technical debt and refactoring. And still another might focus on performing technical analysis, design, prototyping and architectural work. All of these are focused towards underlying support for base functional behavior.

The other difference is that these stories usually need to be defined with someone who understands the technical design and implications of the product stack. Sometimes a traditional Product Owner has the skill to do it, but most often they do not. So this implies the need for team members to “step up” and take ownership of these sorts of stories—not only at the point of definition, but also if there are questions, clarifications, and for sign-off when the stories are delivered.

Functional User Story vs. Technical User Story

The basic User Story is structured towards functional descriptions of system behaviors. Most often the user drives them, i.e., they align with a usage scenario that a customer would follow in leveraging the application or system. On the other hand, technical stories are often driven to support this upper level behavior. I often call them infrastructural stories.

For example, if there were a User Story to allow for logon and authentication of a user to a web based Credit Union application. Suppose there was no infrastructure for web-based authentication within the Credit Union customer infrastructure. It exists for the kiosk-based ATM’s, but would be a new function for the web app. To me this would expose infrastructure that is required to support the base functionality for the Login story. One-way to approach this would be to build this as a function, requirement or dependency within the base story. While that would work, it’s really not part of the function and we’re overloading the story.
Another way to approach it would be to write a Technical User Story. In clear English the story might look like:

We need to extend the kiosk authentication code in our security services layer to include a new authentication mechanism for web-based (browser) applications. It needs to include 2-layer authentication: passwords and user-centric questions.

I could force a typical User Story format on the same story, but I’m not sure it helps here:

As a user requesting authentication,
I need to be able to login via the web app, 
so that I can manage my account details via the web

While this does define the functionality, it doesn’t address underlying infrastructure. You could easily make a note of this on the story, but I personally like the clarity of the technically phrased story. In either case, I believe we need to spend out time writing the acceptance tests. If they’re important for Functional User Stories, I believe they’re doubly important for Technical User Stories. Let’s define a few:

  • Verify that all web-based requests get thru the service layers and receive a reply within 2 seconds
  • Verify that HTTP, Radius SecureID, and LDAP authentication protocols are supported
  • Verify that the authentication timeout performs at 25 seconds
  • Verify that 2-phase questions (3 in total) are presented every 3-5 login attempts
  • Verify that 2-phase questions are applied after a 3x password entry failure
  • Verify that password entry retry limit is set at 5x

I hope you can see how useful the acceptance tests are for this technical story. I hope this example at least gives you an idea of the distinction between the two types.

Mining for Technical Stories

Technical User Stories are often forgotten during backlog maintenance or grooming activity. The Product Owner and the team more easily gravitate toward the functionality and defer the technical infrastructure to later.

This happens for new applications (defining base architecture and design) and ongoing maintenance efforts (extending architecture and refactoring) alike.

One of the best ways to expose technical stories is to perform a Story Brainstorming Workshop as defined by Mike Cohn. I would also include end-to-end Release Planning as another effective tactic. When you take an end-to-end or holistic view to the work to deliver the entire project, then the technical stories often emerge with the discussions.

You can read more about Release Planning and User Story Brainstorming Workshops in the references at the end of the article.

Pay attention to Acceptance Criteria

Very often your acceptance criteria or tests give you hints about technical stories. For example, the acceptance criteria above:

  • Verify that 2-phase questions (3 in total) are presented every 3-5 login attempts
  • Verify that 2-phase questions are applied after a 3x password entry failure

Give a solid hint about decomposing them out of the base story and perhaps creating another Technical User Story that would be focused towards a sub-service related to handing 2-phase questions. I could easily see doing this, particularly if the estimates on the base story are relatively large.

Of course it would create a dependency between the base authentication story and this one, but that might be worthwhile from an implementation and testing perspective. In the end, it’s a decision for the team.

Types of Technical User Stories

Sometimes it’s useful to identify different types of technical stories. Mostly because it gets the team thinking at different levels about all of the needs they might have to properly implement within the application.

  1. Product Infrastructure – stories that directly support requested functional stories. This could include new and/or modified infrastructure. It might also identify refactoring opportunities, but driven from the functional need.
  2. Team Infrastructure – stories that support the team and their ability to deliver software. Often these surround tooling, testing, metrics, design, and planning. It could imply the team “creating” something or “buying and installing” something.
  3. Refactoring – these are stories that identify areas that are refactoring candidates. Not only code needs refactoring, but also it can often include designs, automation, tooling, and any process documentation.
  4. Bug Fixing – either clusters or packages of bugs that increase repair time or reduce aggregate of testing time. So this is more of an efficiency play.
  5. Spikes – research stories that will result in learning, architecture & design, prototypes, and ultimately a set of stories and execution strategy that will meet the functional goal of the spike. Spikes need to err on the side of prototype code over documentation as well, although I don’t think you have to “demo” every spike.

Strategy

Joe Little talks a lot about this in his Release Planning writing—how release planning is really an effort to get the team (and the organization) to move from the tactical (sprint-level) to strategic (release-level) planning. It’s a fairly common agile anti-pattern for teams to fail to look “down the road” in their backlog grooming and backlog management in order to see where they’re going technically. This then drives up rework, unmet dependencies, confusion, and worst of all, disappointed stakeholders when their expectations are unmet.

While functional strategy is important, meaning how will we integrate and demonstrate customer facing stories and features. I find that technical strategy is even more important. Consider this the architectural and design workflow for the development effort. Technical strategy should address functional and non-functional support, end-to-end demonstrability, technical risk, and testing concerns.
Do you DEMO Technical User Stories?

I can’t tell you how often I get “pushback” from my students and coached teams surrounding this point. Usually teams don’t want to demo the Technical User Stories. The rational (excuses) normally fall into the following areas:

  1. There is no UI so we can’t demo it;
  2. They (the stakeholders) only care about the functional software. They don’t care about infrastructure or Technical User Stories;
  3. It’s going to be a very odd demo to show this behavior off IF we don’t have the supporting functional software completed at the same time;
  4. It’s not going to be worth the effort to demonstrate our meeting non-functional requirements (acceptance) for the story.

While I clearly acknowledge that it’s often harder to demonstrate Technical User Stories, I think the payback is worth the investment and effort. Often stakeholders trivialize the technical stories—discounting them as “fluff” that is often low to no cost work that surrounds the functionality. While team members know that technical stories are often quite challenging and consume a large part of the overall project effort.

Demoing the stories and talking about the complexity, effort, and results can truly help narrow this gap for your stakeholders.

Wrapping Up

I actually don’t like separating User Stories into types. So the distinction of Functional vs. Technical to me is sort of artificial. I’d much rather teams simply evolve “all of the stories” necessary to fully deliver “on the goals of a project or release”. So simply put, some of the backlog stories will be:

  • Crucial functionality
  • Supplemental functionality
  • Technical supporting stories
  • Infrastructure – both functional and technical
  • Tooling or architecture & design stories
  • Research spikes

But in the end, it’s for the Product Owner(s) and the Team(s) job to define a robust set of stories that align with the customers’ needs and value proposition and then deliver towards those goals. The product backlog is simply a roadmap that guides the team towards that goal, with continuous adjustments all along the way.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

References

Views: 560

Comment