The way we describe the work for our teams is important, but often overlooked. The description on a card has a big impact on what actually gets built, that is clear. But it also has an impact on the engagement of the team in the work, and ultimately the question of whether they can actually deliver a solution that helps the customer make progress.

I prefer to use the term ‘make progress’ over ‘meets requirements’ because the former is focused on the problem the customer has, while the later is focussed on the solution. Inherent in making progress is the concept of context—the situation in which the customer is trying to make progress.

The problem of how best to define work can be evident at the portfolio (or roadmap) level, right down the stack—however you break things down—to user stories. If stories are prescriptive in nature, this tends to eventually create an environment where the team executes without questioning or thinking. This can lead to low morale because no creativity is required; the team learns to do just what they are told.

The alternative is to define work in a way that invites the team to engage with the problem and the customer directly, creating an environment of empowerment. This does lead to better solutions, and better use of people and their talents. Let’s look at an example.

I once came across a ticket which literally said, “Create a button that provides an Excel spreadsheet download”, with no acceptance criteria. For this discussion I have converted it to the standard user story format:

As a user
I want a button
So I can download an Excel spreadsheet

There are so many things wrong with this story. What type of user? What is the context they are in? Why a button? What will the spreadsheet be used for? What fields from the data are needed? Why Excel? What about design?

Even if the team is just focused on delivering features, they are going to have to talk to the user before they can start work. In fact, it would be hard to imagine this even getting past planning as there is too much unknown.

The product owner was able to add additional information for me: the user wanted the data in a spreadsheet so that they could sort it. The story could now be updated:

As a user
I want a button to download an Excel spreadsheet
So that I can sort the data

This is a (very) minor improvement in that we now know what the user wants to do with the spreadsheet, or rather with the data, but little else. It is still focussed on the solution though, and the real progress the customer wants to make is outside the domain of our software. But is it really?

Why do they want to sort the data? A deeper discussion with the customer revealed that they want to sort it by most recently updated time. After that, the intention was to go back to the web page, and scroll/paginate until they found the item they wanted in the alphabetical listing, before clicking through. This seemed a bizarre way to work, founded on an apparent lack of understanding of what was possible. The customer was apparently under the impression that the page listing the data could not be changed.

As it turned out, the customer would enter data for new items, and wanted these recent items at the top of the list as these were of active interest in day-to-day operations. It is pretty clear that the spreadsheet was a workaround because the user could not make progress on the item listing page. Let’s change the user story to document the context and the problem:

As a user creating new items
I want to be able to quickly see the latest items later
So that I can easily access them again if needed.

This is a much better place for the team to start the conversation. This has changed the focus of the story from one solution, to showing the context the user is in and the progress they want to make. There are now many possible solutions.

Yes, a spreadsheet works, but is clearly a horrible solution. The sort order on the page could easily be changed. Perhaps better, the product team could have a session with the user to better understand their typical workflow. They might learn that user enters five or six items at a time, goes and has a coffee, and them comes back to check their work and make any corrections. Or they might find that the user comes back to the list only after the item has started selling. The team might look at usage metrics and find that that this pattern is common among customers, suggesting a recently changed items area might be more useful. Any or all of these could be quickly prototyped, tested, and iterated upon. A conversation, and the solution space, has been opened up.

As it transpired, the actual change made was to add a button to change the sort order between ‘alphabetical’ and ‘date added/updated’. Ten minutes work to build and deploy, vs many hours to add and test a spreadsheet download.

This is a trivial card, based on real scenario, but it shows that the way work is specified (as a problem or solution) has a big impact on the final shape of a product, for good or bad.

When this solution-based approach is applied at the top of the product funnel, into roadmaps or epic backlogs, it creates a bigger problem. As these larger high-level features (as they must be at this level) are broken down without context, you can end up with functionality that does not makes sense, or does not integrate well with what already exists.

During the process of breaking the feature down, the team will discover that there is information they need, and that other parts of the system will be impacted by the feature that weren’t anticipated. Any estimate of the time that feature will take to build will, of course, be wrong. (It will always be wrong.)

One example of such a high level feature is “Add text two-factor auth to the log in process”.

If you were working on that a few years ago, sending a second factor via text was considered OK – safe in most cases. These days it is being replaced by authenticator apps due to concerns around SIM hijacking. The other thing is that being specific about the solution locks the team out from looking at alternatives. In the worst case, the stated solution may incur more technical debt than if the team had been allowed to find the best solution.

We could state this in terms of the problem, “We need a way to confirm a customer’s identity when they log in”. This opens up the solution space for the team to explore. Is SMS secure? Do we need passwords at all? Should we be using a seperate token generator. What is our risk profile? What are others doing? These are questions which might not have been asked at the roadmap level. An executive might have used SMS 2FA on a social media site, and it looked pretty simple, so let’s do that! It can’t be much work, perhaps a day or two.

Oh dear!

A roadmap, if one exists at all, should be strategic in nature, and outline the high level customer problems we want solved in the near future, and the order we’d like to solve them in.

Have a think about your past backlogs. How many times did you have to drastically change a card written months or years ago, or deleted it because it was no longer relevant or was overtaken by other events? How much time was spent making the original card?

If these items were simply stated as problems, the conversation changes from ‘do we need this feature’ to ‘does this problem still exist’. In the case of latter, it may have already been partly solved, requiring a restatement of the problem with a reduced scope.

The description of the work should not be a prescription. It should be invitation for the team to discuss and explore the problem and solutions, and to experiment, gain feedback, and improve a solution, or start over. Working with the customer, every step of the way, to ensure that only software that has value is shipped.

What causes this?

In order to move on from solution-focussed cards, it is helpful to understand the forces that conspire towards stories being written as solutions.

Here are some:

1. We have always done it that way / that is how the framework ‘X’ does it

If you are not getting the results you expect from the way you do things now, then perhaps it is time to change?

2. An experienced product person ‘knows’ what the solution needs to be.

“I have been doing this for 25 years. I know the customer. You are just a developer.” (add yours.)

It may be the correct solution today (or yesterday), based on the current context and user needs, but what about tomorrow, next week, or next month? If the context changes, the solution may no longer be appropriate. If the team are only told what solution to build, without any context, or the progress the customer is trying to make, they won’t have the information they need to change the solution if they need to (assuming they are even allowed to).

If we just tell the team what to build, where is the fun in that for the team, especially if we are wrong?

3. The customer asked for it.

This is cited as a strongest reason to deliver just what was requested. The main issue is that it may not be the best solution because the customer does not know what could be built, only what they have experienced in the past.

Let’s say, in the spreadsheet example I gave above, the customer has never experienced column sorting in a web browser, and had only had exposure to this feature in a spreadsheet. They would naturally tend towards the only solution they currently know.

The product team, more broadly, knows about many possible solutions already, and they also have the skills to explore beyond what they already know, to come up with something that helps the customer make progress.

4. It was handed down from sales, an account executive or ‘the boss’.

Another problem area is that many sales and account executives are automatically in solution mode; they want to solve the customer’s problem as quickly as possible, and will jump to the first thing that seems like it would work. KPI (and sale) achieved!

The problem here is that the solution may have been sold with a deadline, and without reference to the current roadmap or strategy.

In some cases, the feature comes from ‘the boss’. They saw this feature in a competitor’s product, or they just want it done.

Sadly, in many cases these solutions don’t help the customer make progress, and what is put forward is an amalgam that makes little sense in the current reality of the team.

This is not an exhaustive list of causes, and you are welcome to contribute more in the comments.

These forces can be strong, but if we want to empower our teams to build and deliver more value to customers, it’ll require different approaches to work, not just that way cards are written. But I do think that changing the way we frame the teams work is a good start on that journey.

Sadly, changing from a solution to problem/progress-focussed approach is not as simple as throwing a switch. Old habits die hard, and a change of this kind requires changes in behaviour right through the organisation. Good luck on that journey!