We need to generate a release in 3 weeks, and for the planning we are doing today we don't have coherent logical user stories from the backlog tasks. Is valid to match say each development task is equivalent to an user story?

Methodologically what is the correct way of handling this?, because anyway we are going to have standup meetings and we are going to control the progress of the project against those development tasks.

For example, we have things like:

. Adapt ETL to process numeric lists

. Adjust licensing component

. Remove DTC

and so on.

So, for the planning poker and iteration planning is valid to use those tasks? if not, what is the alternative?

  • 3
    There isn't much you can do to fix this problem in a 3-week time frame. Do your best you can to get the release out in 3 weeks with the information you already have. When you complete the release, include a list of discrepancies, including the lack of user stories. Commented Oct 22, 2012 at 18:22
  • 1
    If you are using poker cards to estimate user stories you will probably know that a user story can be worth anything from 0.5 points to 40 points. So I do not see a problem having mini-user stories for these small tasks. I think this is a better solution than grouping these small tasks into artificial user stories just because it feels awkward to have small user stories.
    – Giorgio
    Commented Oct 22, 2012 at 18:25
  • Hi, I'd like to upvote your comments being answers as I think they provide value and not are only side notes.
    – Alex. S.
    Commented Oct 22, 2012 at 18:42
  • Why are you doing these things? What value does it offer to the business? If it has value, you have a story, you just have to think about it a bit harder. If it doesn't, you shouldn't do it.
    – pdr
    Commented Oct 22, 2012 at 20:23

3 Answers 3


You may want to consider a change to your process- generate development tasks from user stories, not the other way around. User stories have a business value built in.

For example, the adjustment to the licensing component: If you can express that as a story (As [a type of user], I want [some feature] because it will give me [some business value]), then go ahead and make the adjustment.

If you can't find the user and the business value, that should be a clue: don't do that work! Do something else instead.


Yes, it's valid. Tasks are stories that haven't been expressed yet.

A story represents something created by a company which gives value to a customer. Identify the customer of each task (it's ok to have an internal customer), then define the value to that customer. Define your done criteria and you have a valid story.

If you can't identify the user, and/or if you can't identify the business value, you should rethink why you are doing the work. You should always be providing some value to somebody.


The simple answer is to just write stories for the tasks. This is actually an opportunity to validate (and reconsider!) the business value of each task.

For example,

  • As a [developer], I want to [Adapt ETL to process numeric lists], so that [numeric lists don't crash the server]
  • As a [developer], I want to [Adapt ETL to process numeric lists], so that [numeric lists can be imported into the data warehouse]

it's even better if some value is identified for the users other than the developers, e.g.

  • As a [data warehouse manager], I want [ETL to properly process numeric lists], so that [daily operational statistics can be correlated to the widget production]

If you can't find any business value/impact for a task, reconsider doing it at all.

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.