What do I mean by high-level plan? The kind of plan that outlines product's functionality that needs to be developed but not going into too many details that are done afterwards. This kind of plan helps deciding functionality development order (priority) or even eliminating non-necessary ones. A great high level plan isn't just a set of functional requirements, but rather a product vision with obvious goal in mind.

In Agile terms these kind of functionality documentation is the Backlog. We're used to its content - user stories - as defined by Mike Cohn that go:

As a role I want functionality so that benefit.

But as we know from experience this may lead to:

  • unusable stories
    Like: As a visitor I want to login so that I'm allowed to do stuff.
    But how would one improve this user story? What other benefits can we describe that are more relevant than ...do stuff?
  • flat list of unmanageable seemingly unrelated stories
    Hard to see which ones are related or not (they shouldn't be but I don't think we can totally avoid this), or even which ones provide means for achieving the same high-level goal.
  • too many unrelated goals/benefits
    Goals just because we need to write them but without actual business value benefit - the high level business goal in mind.

The problem

As I have experienced there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful. And how can one write better user stories when they are working on their own product, so they don't have means to learn from other fellow team members, and they have to provide user stories now. Not after 6 months of learning.

That's why I would like to know about alternatives to planning a project on the high level that ensures better feature description and relevancy. I've heard of Effect mapping that seems very good in keeping goal focus and filtering relevant from irrelevant but I don't have any experience with it. I can imagine that setting a goal can be crucial. So if you set it wrong, everything else is wrong as well. Or better said irrelevant.

The main question is: Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan. A guideline that allows less errors and better leads to valuable plan/results. I can see myself writing user stories afterwards that describe features to implement. The problem with user stories is that it's easy to get lost in them. If you don't have lots of experience with user stories that may hinder your product because they distract you from the actual goal. All you can see are product features described in user stories. Something else above that would allow us to create better stories and also easily filter out those that are extremely relevant.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Focus of this question

I have been writing user stories on several projects in the past and know exactly how hard and vague this task is. I've also seen that writing these is even harder when you're writing them for your own project/product. You can easily over-design your product or incorrectly prioritise/evaluate features.

So I would like to write feature set for my coming product in a way they are actually relevant and prioritise them accordingly to reach my goal as reliably as possible.

So feature relevancy and quality along with goal-oriented prioritisation. And I'm talking about measurable quantitative goals like

20% month over month income increase or
5% sale conversion rate of user visits

and not something vague like increase users or increase sales.

We can see that writing relevant features that support these goals is much harder.

  • @RobertHarvey: Why don't you write an answer because it seems you have suggestions to many issues I've pointed out. Commented Dec 27, 2011 at 21:02
  • Define "great high-level plan".
    – S.Lott
    Commented Dec 28, 2011 at 2:30
  • @S.Lott: Edited my question to define the high-level plan at the top and afterwards. Commented Dec 28, 2011 at 11:05

4 Answers 4


There are two parts to this: QA and Planning.


there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

How true.

That's true for software. Woodwork. Plumbing. Painting. Walking down stairs.

In all cases, we have a technique for preventing all the bad/unusable from overwhelming the good.

It's called "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Without Quality Assurance, nothing works any better.

I've heard of Effect Mapping ...

Without Quality Assurance, this technique will be just as bad as user stories without Quality Assurance.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Not really.

It turns out that it's hard. You can't get a "great" plan without "great" user stories. And you can't get "great" user stories without some definition of greatness and the Quality Assurance to establish their greatness.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Nothing is more reliable than user stories. Or. To be more precise. The reliability stems not from the technique, but from your Quality Assurance. With poor QA, all techniques are equally poor. With good QA, all techniques are equally good.

Apparently "Quality Assurance" is not a popular term for Quality Assurance. If you want to call it "Verification and Validation", you can call it that instead.

You already have quality standards that you deem important. You listed them in the question.

What you're not doing is assuring that all stories meet the quality standards. What you need to do is to assure that all stories meet the quality standards before you use them for estimating.


You probably have unrealistic expectations for a "a great high-level plan". If you think you're going to estimate to within a small factor of the final project cost, you're being naive. You're initial planning is not actually of any value at all.


The Agile (specifically Scrum) folks will tell you that the backlog is a very, very flexible thing that grows and shrinks wildly as people learn about the product, the stories, the technology and the problem domain.

The initial estimate is not really useful for anything, since many of the low-priority user stories can easily be removed. Some of the user stories are really epics with numerous user stories buried within them. Some of the user stories are flat-out wrong. And some of the user stories only hint at the real problem that needs to be solved.

After a few sprints, the backlog combined with the delivered features looks very little like the initial backlog. This is the sign of a well-run project where people have permission to learn something and fix the backlog to reflect that learning.

"leads to valuable plan/results." is a backlog. Not much more than a list of stories and relative complexities. Detailed estimates based on super-accurate stories don't actually help develop software. All that detailed estimates help with is estimation.

"A great high level plan isn't just a set of functional requirements, but rather a product vision with obvious goal in mind" Is a backlog. Nothing more. Detailed estimates. High quality user stories aren't essential. Bad user stories are part of a great plan because they get reworked to improve their quality.

  • 2
    This is a great answer, but isn't "Quality Assurance" a bit vague? Do you mean that OP should find someone responsible for the quality of user stories? Wouldn't that be a task for the marketing team? Commented Dec 28, 2011 at 1:45
  • "find someone responsible for the quality of user stories"? No. Everyone is responsible for the quality of the user stories. QA is not a task you delegate. It's something everyone participates in. The marketing time, the product owner, the development team, everyone is responsible for story quality. The same way everyone is (eventually) responsible for delivered software quality. And documentation quality.
    – S.Lott
    Commented Dec 28, 2011 at 2:22
  • My intent is not project estimation but rather filtering the good features from the bad ones. This will eliminate some requirements that don't add much to the overall goal. What I'm after is a great prioritization technique that will get me faster to First Release. Commented Dec 28, 2011 at 11:42
  • @RobertKoritnik: "after is a great prioritization technique" If that's what you want then actually ask that. Update the question to focus on what you want to know. Please help by making sure that you question has the correct focus.
    – S.Lott
    Commented Dec 28, 2011 at 12:05
  • @S.Lott: Added additional info to better focus my question. Commented Dec 28, 2011 at 13:25

In our development group we use Scrum and manage the product and release backlog using stories alone. Few tips that could help you:

  1. Don't write very low-level stories early on. If you are planning a release that is 6 months out, no need to fill backlog with 1-2 point stories. That creates too much to manage. Instead, define larger chunks (i.e. epic stories). Break down more important ones which you will start working on first, but leave the other ones at high point estimate. That will help you keep number of stories in the backlog low

  2. As others pointed out, story hierarchies are your friends. Which ties into (1). When you get to a point where better estimate is needed take your Epic (or plain large) story and split it into smaller stories which will become it's children.

  3. In the past, our backlog appeared as unmanageable mess of stuff which served no predictive value. The key, which we've learned in the last release, is to continuously do some form of release planning and periodically check to see what is in the backlog. The order of stories should match the priority in which these stories should be done. As priorities/requirements change, backlog needs to change with them. Periodic reviews will

    • ensure the team knows what's ahead and
    • keeps the backlog from becoming a dumping ground
  4. I read this somewhere (either a book or a blog, but don't remember where). The author suggested that backlog should never be planned out more than 12-18 months in the future. He said that even if there are "important" items that you think you will do in the next release, you don't need to actually write them down and have to manage them. If they are truly important, they'll come up in the next release planning.

  5. What's the size of your team? We've split our development group into 3 separate agile teams. This way we have 3 scrum masters, 3 planning meetings and each team only has 1/3rd of the stories that they actually need to manage and shuffle. Our team was split based on functional areas of the product and then the functional areas were adjusted for equal load.


Gathering requirements is not always easy, it needs almost always some experience. The "user stories" approach is just a tool which might help you to have a unified form of writing down your missing product features, but don't expect it to be a silver bullet. If you need other forms of requirement specs on a different level of abstraction, don't hesitate to create it.

Actually, I don't believe there is is an easy-to-learn guideline which can help you - just practice "requirement engineering", and after doing this for some months, you will get better in this job. Moreover, you have already identified some crucial points you want to avoid, which shows you are already on the right track. And if you are missing the "great high-level plan", why don't you try to write down some general, high-level project goals beforehand? In most projects I have participated, that was the easy part - the hard parts are always the details.


As a visitor I want to login so that I'm logged in -- Bad example. Better example: As a visitor I want to login so that I'm allowed to _______.

flat list of unmanageable stories -- Arrange them hierarchically, by functional areas. As a logged-in user, I want ____ so that ____ or, as an Accounting user, I want ____ so that ____

too many value-less goals -- Stop writing those.

Can we follow some easy to understand and narrow guideline -- Does this User Story lead to meaningful and testable requirements?

  • How do you suggest we should hierarchically arrange user stories? By roles? By benefits? by anything else? Commented Dec 27, 2011 at 21:04
  • I suggest arranging them by functional/feature areas and sub-areas. Some User Stories will naturally open up a new group of sub user stories. Commented Dec 27, 2011 at 21:06
  • You can remove (strike through) the first suggestion because my example user story in the question has been changed some time ago. Commented Dec 28, 2011 at 11:43
  • When you say stop writing those sometimes it's not easy when you define features for your own product where you have to do planning, managing and developing. Sometimes certain stories seem viable, but may turn out to be total crap... Commented Dec 28, 2011 at 11:45
  • "As a user I want to be sure that only I can do cool stuff in my name." Logging in is not a story, no-one ever wants to spend their working day logging in. It can support a well-written user story, though.
    – user4051
    Commented Dec 28, 2011 at 12:16

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.