I have a colleague at work that appears to stuggle with writing concise user stories with a set goal/ acceptance criteria and has asked me to review the ticket he assigned to me.

We use Azure DevOps Boards at our workplace and are loosely following a Kanban method.

The User Story outlines a piece of work that needs to be undertaken in order to develop a 'data platform' for our organisation. A place where we can process our existing database data for data analysis/ querying.

The description reads:

As an Engineer
I want a data lake with data engineering and data integration, all in one place
So that data is democratized throughout [company name]
and so that Spark jobs can be scheduled
and so that interactive computational notebooks can be created and shared
and so that data can be efficiently analysed and modelled
and so that large data sets can be managed and queried
and so that data can be processed and analysed in real time
and so that the creation of interactive, real-time visualisations and reports can be democratised
and so that our preferred analytics tools can be brought to the data, rather than requiring the data to exported to the tool
and so that administration, permissions and governance rules can be configured and applied centrally across all underlying services

As a DevSecOps Engineer
I don't want to worry about managing the hardware and OS for this service.
I want a SaaS solution
So that I can concentrate on the business logic and the areas that add value to [company name] and our customers

A number of specific spikes, tasks and deliverables will be identified and delivered incrementally. Please see child and related tickets for the details.

I know this specific user story is incredibly broad and should ideally be split into several specific requirements/ tasks, with acceptance criteria but I don't really know how to get back to him with constructive feedback regarding specific aspects of this ticket - in order for it to make sense to him.

Can anyone point out any best practices that he is breaking here?

  • This person is likely to be used to writing BDD using Cucumber, which is not really the same as a user story. Just explain that a user story is a conversation placeholder, or at most a 2-3 sentence summary of who cares, why they care, and just enough context to start a conversation about it or limit the solution space. The rest of it belongs in a separate place than the user story, such as a Definition of Done, an acceptance test, or just about anywhere except the user story or main ticket.
    – Todd A. Jacobs
    Mar 6 at 0:34

3 Answers 3


First of all, a User Story that starts with "As an Engineer I want a data lake..." isn't a User Story. User Stories are written from the perspective of the user of the application, i.e. a customer. For more details about some good rules of thumb to build a user story see this page for example.

In this example, this can be split into multiple technical tasks, each with their own list of acceptance criteria. Those "so that" statements can either become acceptance criteria for one task, or can themselves become other tasks. It depends on your setup which will be which, based on how it makes more sense to split them up for implementation.

This could be the result of two things:

  1. someone said - or someone assumed - that everything in the backlog should be a user story. So that's what you have, no matter if it makes sense or not. This is fixed by recognizing that you have multiple types of work items in the backlog and details captured need to be clear, not necessarily forced into some template that might or might not make sense.
  2. A failure to refine or decompose work into more actionable pieces and working incrementaly towards the final solution. This is fixed by practicing more decomposition of work, discussing the parts, identifying dependencies, see how you can integrate them back together, etc (technical breakdown in case of implementation, or refinement in case of requirements).

User Stories have that format to put in context the value you should be delivering to users (and other advantages). You can always build features or get dragged into discussing the technical details, but what result do you want, for whom, and for what?

You can keep the format for technical stuff like "As an Engineer I want a data lake..." if it's more clear that way and if it makes sense, but then just call it simply a Story, not a User Story. But definitely do break it down into more stories, not one with a large list of "and so that".

  • The modern take on user stories doesn't require the perspective be a customer or end user. It's just the value consumer of the story, or may be a persona or part of a conversation placeholder, e.g. the person you should be talking about the implementation details with. A user story such as "As a database administrator, I want port 3306 opened on the firewall so I can connect to the database from my desktop GUI instead of having to use the CLI on a remote host over SSH" is a perfectly valid user story even if the database is just part of developing a Soylent Green direct sales product.
    – Todd A. Jacobs
    Mar 7 at 0:09
  • @ToddA.Jacobs: Yes, but without the need to develop a Soylent Green direct sales product, there wouldn't be a need for a DB administrator to open firewall ports to connect to a DB that maybe would not exist. So, access through GUI or CLI wouldn't matter anymore. Plus, the DB administrator is not a user of the Soylent Green direct sales product. I agree with your comment, but I prefer the distinction. As I said, the same template can be used everywhere, but I prefer a User Story or just a Story depending on the perspective from which you look at things.
    – Bogdan
    Mar 7 at 8:09
  • My comment was more for people like the OP's engineer than for you. "Where's the value?" is part of the OP's issue. I'm just saying that not all story-level work items can be expressed as user-facing value streams. Some work is architectural runway, fulfilling non-functional requirements, process improvement, or other stuff that's more than a task or chore but less than a feature. If you can roll them into a vertical slice then I agree that user-visible stories might be the best place to include them, but one shouldn't have to contrive fictional user value to express them as stories IMHO.
    – Todd A. Jacobs
    Mar 7 at 19:52

As an Engineer I want a data lake

This is what I call a "As a horse, I want to draw the merchant's cart to the market" story.

No. The horse doesn't. It wants to be fed and left alone. The engineer wants to be paid. Nobody wants a data lake. The data lake may be the solution to a problem someone wants fixed. But it is not the thing people want. If their problem could be fixed by something else, they'd be just as happy.

This happens when you don't actually write user stories, you just told someone that their request of what is to be done must be in the format of a user story. Then they will take what they think must be done and format it accordingly.

A user story needs to start with the requirement from the actual user. "As an accountant, I want to be able to schedule regular calculations of quarterly numbers so I have the latest numbers to work from every morning.". Now you can determine that in your company that is a Spark Job (whatever that is) and that you need a "data lake" to do it. But that is not the requirement. It is the proposed solution. If 2000 talented chinese Mathematicians in a warehouse could do it in their head for a tenth of the price whenever you send them a chat message, nobody would talk about wanting a data lake.

The requirements would still be the same though.

What you have on your hands is not a user story. It might be valueable information to a set of problems, those should be user stories. This looks more like the result of a meeting on how to tackle all the proposed requirements of your user stories.

You forgot that it is the merchant who wants to transport goods to sell them at the market and jumped straight to the horse pulling the wagon. The user story is the merchant needing transport though.


Decompose to INVEST

In your own question, you correctly identified the need to decompose this "story." A good product backlog item meets INVEST criteria, and should be:

  1. Independent or self-contained.
  2. Negotiable, with room for discussion about scope or implementation.
  3. Valuable to a stakeholder (which can include engineers), but with some definition of what that value actually is, e.g. "why?!"
  4. Estimable, which pretty much implies small, independent, and with a clear "Definition of Done." You must always be able to estimate the size of a PBI.
  5. Small, which this sweeping saga of a ticket is not.
  6. Testable, which means having a Definition of Done and clear success criteria.

Define a Critical Path or Stepwise Execution Plan

This breathtakingly overloaded backlog item is not in any way plannable. By that, I don't necessarily mean you need an exhaustively formal plan, or to define the plan using the Critical Path Method (CPM). Overly-detailed task lists won't help much, either. However, any project goal or milestone ought to have some clearly defined (and ideally incremental) steps towards being "done."

No matter how many tasks you assign to a ticket like the one posted, the dependencies between tasks and the ability to determine if any set of interim steps is "done" is practically non-existent. This is really just a wishlist of undefined (and largely undefinable) pseudo-objectives. For example, what exactly does it mean in your organization for data to be "democratized throughout the company?" What data? What does it mean for that data to be "democratized?" And why does the entire company need this democratized data anyway?

Furthermore, even if you define all these things, how does this person expect to work incrementally or iteratively on this? What are the sequential or parallel steps that can be taken? What does sharing of Jupyter notebooks or similar have to do with real-time scheduling?

In other words, none of this is actionable, and no amount of circular references will make it plannable. A project is a journey with a beginning, a middle, and an end. Pieces of a project also need a clear path from "not started" to "fully complete."

An Effective, Hands-On Project/Product Planning Exercise

Take away this person's keyboard for an afternoon. Hand him a pen, a supply of 3"x5" sticky notes or index cards, some push pins or removable tacky hooks, and a spool of string. Have him write a measurable goal on one card and stick it on the right hand side of a large board or wall. Then have him start on the left-hand side and write out the steps he needs to take to get to the goal.

If the board fills up with notes, hand him the push pins and ask him to run the string from the first story to the goal through whatever maze of stepping stones he needs to follow. If he can't "connect the dots" from beginning to end, or if the string becomes an untraceable cat's cradle or a Gordian knot, then the plan is too complicated; he'll need to revise it or start over. If he succeeds, he's now defined his critical path from start to finish. Yay!

This works really, really well as a live exercise. It works less well as a thought experiment because the person doesn't get to really feel the complexity they're creating without decomposition or clarity on how they expect to execute the plan. This activity generally encourages people to optimize for the shortest path with the clearest goals. It rewards the agile principle of "optimizing work not done" by being flexible about scope and implementation details, but prevents people from skimping on articulated increments of "done" needed to reach a goal.

In other words, you're encouraging the person to reframe what planning is all about. Good engineering isn't about building a Rube Goldberg machine; it's about taking small, incremental steps towards the simplest thing that could possibly work. Once you have that shared understanding, you'll both be in a better position to collaborate on refining these stories into something more practical.

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.