1

Problem:

During user research phases I document user needs as user stories. Then we brainstorm high-level solutions before it's time to turn them into real features.

I'm having trouble referencing the ideas throughout the development phase (roadmap/sprints). I find user stories lacking the actual solution. I know it's the point but in my experience, this leads to quick and unimaginative solutions if we try to solve the needs during production.

An Example:

Let's say you are creating a grocery shopping app.

One user need might look something like this: "As a [user persona] I want to quickly order previously purchased products so that I don't have to spend unnecessary time in the app."

This user story could then be met in several different ways. The team (including PMs, designers, and developers) could for example come up with the feature "Quick-add" and a better autocomplete-search feature.

We could then make some quick sketches and a rough estimate – how long will it take to develop these two features? And then, we could prioritize which one of these two feature ideas that's worth pursuing.

Question:

– How do you document and reference the features in a roadmap – do you just call it "Quick-add" or rewrite the feature as a (new) user story?

4 Answers 4

1

I find user stories lacking the actual solution.

User stories are not static. They evolve through their life by the addition of more detail.

The lifecycle of a user story goes something like this:

  • Early on: A simple "As a..." user story that helps with prioritisation and with discussions with stakeholders
  • Middle-aged: Some details have been added, such as acceptance criteria
  • Close to the time that development starts: Implementation details have been added and possibly spikes have been done to decide on an approach

User stories lacking the actual solution is deliberate as it delays the investment of time and energy in the story until the last possible moment. This is because being agile is about rapidly adapting to change.

I know it's the point but in my experience, this leads to quick and unimaginative solutions if we try to solve the needs during production.

This is the problem you need to address: How do you add details to your stories in a timely and effective fashion?

Experiment with how early or late in the lifecyle the user story gets fleshed out. Try and find a good balance between agility (not committing too much time to a story early on) and preparedness (avoiding insufficient detail at the time the work starts).

0

User Stories Used as "Features"

"As a [user persona] I want to quickly order previously purchased products so that I don't have to spend unnecessary time in the app."

What you're missing here is really either a Definition of Done or some testable success criteria. Thinking about the story through the lens of the INVEST mnemonic might help. In short, while this might be a "feature" it's not really small, testable, estimable, or (quite likely) independent.

Good User Stories are Implementation-Agnostic

In addition, you're correct in saying that:

This user story could then be met in several different ways.

Items on the Product Backlog can be met in various ways. The Product Backlog describes what, while the Sprint Backlog (which is developed during Sprint Planning) should describe how. If there isn't a clear-cut answer, then the team can either:

  1. Add a short story spike or two to the Product or Sprint Backlogs to determine which approach meets the needs best, whether that's because it's faster to implement or delivers more value.
    • Which backlog is used will depend on whether the story spike is related to the current Sprint Goal, or to help decompose future work on the Product Backlog.
    • Since a story spike is a type of validated learning, the learning from a story spike need not be used within the same Sprint. While a Sprint should have a Sprint Goal, as most of the work in the Sprint should be associated with that central cohesion, that doesn't mean that relevant learning, building technical runway, or other items can't be on a Sprint Backlog. Just ensure that chores and spikes on the Sprint Backlog don't interfere with delivery of the Sprint Goal!
  2. Pick an approach, deliver it during the Sprint Review, and then iterate over the feature as "new work" in a future Sprint.

Either approach is viable. It just depends on what your Scrum Team's priorities are.

Consider Epics and Themes

"Features" isn't really something defined by Scrum, nor a term with a 1:1 mapping in terms of one or more user stories. If you're finding that a feature doesn't fit as a user story, consider abstracting features (along with a good Definition of Done or testable success criteria) into:

  1. Epics

    Larger stories that require multiple stories to complete, or that can't fit into a single Sprint without decomposition.

  2. Themes

    A group of related user stories that have some sort of cohesion. These may or may not be tied to epics, but because they are related rather than dependent on one another technically themes can cross Sprint boundaries. NB: You may not hear the term "themes" as often as "epics" in the field because a lot of ticketing systems like JIRA don't natively support them, but Mike Cohn and others who write about user stories use the term frequently in various books on the topic.

0

great question, I have been in this situation so many times.

So lets work through the example. The user has a need to quickly add previously purchased items to the basket. This is your epic, feature or high level story - depending on your tooling. Essentially this will be a container for the work required to take that particular feature from idea to done and released. You will most likely report at this container's level to stakeholders like your senior management and customers.

For this example, lets say you start with an Epic named "Quickly add Previous Purchases to Basket". This Epic should describe the required functionality and the acceptance criteria.

So at this point you have an idea and the status of this Epic is something like "idea" or "funnel", basically it's an idea pre-analysis.

Now you capture the stories to move this Epic from idea to ready for work under that same Epic. The Epic is then in "analysis" and depending on the complexity of your system and this idea, you will have stories like, "customer research", "security and data governance", "high level design", "ROI calculation". So you are reporting to stakeholders that the feature ( this Epic ) is in analysis so we don't know how long it will take yet but are figuring that out. Of course the analysis phase might be very short for simple features.

Once those analysis stories are out of the way, you do a 3 amigos meeting and write the implementation stories and give the Epic a high level estimate. The high level estimate could be a t-shirt size at this point. You can't really estimate at this point as you need the whole team for that and generally they won't all be at the 3 amigos meeting.

Now the Epic can be move to ready for work and the stories are subject to backlog refinement and sprint planning where you prioritise and estimate. At this point you have a clearer picture of the work required and the order in which you will approach that work. Depending on how you release you should be able to attach a release to the stories which represent an initial valuable drop to the customer.

Once you start work on the implementation stories, your Epic status is "Implementing" and you can report on story and release progress based on the story estimates and release date and your capacity projection ( velocity ).

Hopefully that helps.

0

but in my experience, this leads to quick and unimaginative solutions if we try to solve the needs during production

The key thing you appear to need is a 3 amigos meeting which will give the opportunity to really explore some ideas as well as reduce ambiguity. In my experience, when a 3 amigos meeting is skipped (one 'amigo' may have been absent for one reason or another) it's always led to inconsistency of result and additional pressure on the whole team.

If you're already completing a 3 amigos meeting, perhaps review what the goal of this meeting should be, quite likely your issue will be resolved as a result.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.