We are organized around a Scrum process with 2 week sprints that utilize Project -> Epics -> Features -> Stories -> Tasks I am assigned to an Epic expected to take 3 developers for 6 weeks. The Epic contains 10 features with an average of 8 user-story cards per feature. The features roughly equate to a web page. User Stories are things like:

  • 101 get the customer info from API
  • 102 display on the panel
  • 103 Let user pick the options they want
  • 104 verify the user entered date
  • 105 do not leave page until all required info provided

The question I have is: “When is the best time for developers to break Stories down into Tasks?”

  • 3
    You're question is unclear. Can you please try to clarify?
    – RubberDuck
    Jun 14, 2017 at 22:51
  • 1
    The assumption "an epic expected to take 3 developers for 6 weeks" is not what Scrum is meant for. It is uncertain when the whole epic is done (maybe the features change, new ones come or other will leave over time). The priority of the stories is made by the product owner, for example regarding the business value of each fetaure. The only thing done by the team is estimating each feature and think how many of them will be done in current sprint.
    – ppasler
    Jun 15, 2017 at 11:29
  • 2
    @RubberDuck Pretty sure I understand what the intended question was, and have edited the question appropriately. The OP can correct my edit if it was wrong.
    – Sarov
    Jun 15, 2017 at 13:44
  • 1
    ppasler says 'The assumption "an epic expected to take 3 developers for 6 weeks' is not what Scrum is meant for ". I know, but the people with the money make the rules. They gave me a project to implement and they gave me a time frame. My choices are to do what they say or collect unemployment.
    – rwg
    Jun 18, 2017 at 22:28
  • 1
    and to continue, I want to thank everyone for their comments, but point out that big companies with monolithic applications needing to be replaced is a different chore than working in a modern designed application. Once we replace this (20 epics or so) which have to be replaced all at once for user experience we can do true Epic work.
    – rwg
    Jun 18, 2017 at 22:41

5 Answers 5


I am assigned to an Epic expected to take 3 developers for 6 weeks.

There are so very many things wrong with that statement, from a Scrum perspective. I'll go through them in order.

I am assigned to

Scrum works better as a pull-model, not as a push-model. No one assigns work to developers. In the Planning Meeting, the Scrum Team accepts work from the backlog (with the Product Owner prioritizing which work is most important, and the Development Team deciding how much they can get done that Sprint). During the Sprint, developers will, on their own initiative, pull down unassigned work and start working on it.

Epic expected to take

Epics are not estimated. They are far too large and nebulous to estimate accurately, so attempting to do so does nothing but give a false sense of schedule-security.

3 developers for 6 weeks.

Two things wrong here. First, estimates should be done in terms of relative effort (story points), not time. Second, instead of estimating in x-points-for-y-developers, just estimate for x-points. Otherwise, you are locking yourself into how many developers will work on the Epic, which is distinctly un-Agile.

Now, to answer your actual question,

When is the best time for developers to break Stories down into Tasks?

The answer depends on whether or not you are actually doing Scrum. If you are, then the answer is during the Sprint Planning Meeting (or, as some Teams do, during the Pre-Planning Meeting).

However, it's looking like your company does not really do Scrum. The commonly accepted word for what you're doing is Scrumbut. So your two options are:

  1. Try to convince your company to switch to actual Scrum. If the reasoning behind this particular version of Scrumbut was something along the lines of: "This Scrum thing looks nice, but we probably don't need this, and this, and this..." then take a look at We Tried Baseball and It Didn't Work.

  2. Ask your company how they intend to implement their particular version of Pretends-To-Be-Scrum-But-Actually-Is-Not-Even-Agile. Because we, not being part of your company, cannot really answer that question for you. Keep in mind that it's possible there might not be anything actually wrong with what your company is doing, from a business-perspective... but calling it Scrum is blatantly false. As the Scrum Guide notes:

although implementing only parts of Scrum is possible, the result is not Scrum.

One final thing, you might want to look into how you're defining User Stories. A commonly-used format is "As (identity), I would like to (action) in order to (reason)." See the INVEST mnemonic for more details.

  • Nice - you made every afford to explain this in particular, but maybe OP should start with the Scrum basics from scratch.
    – ppasler
    Jun 15, 2017 at 13:50

Please allow me to answer your question as presented first, and then broaden my answer.

When is the best time for developers to break Stories down into Tasks?

At sprint planning at the beginning of the sprint. This is what we would call the "last responsible moment". They need concrete places to start working but they know the most about the work that needs to be done right before they start the sprint.

I would also recommend reading this blog post from Mike Cohn which takes the "last responsible moment" idea a step further: https://www.mountaingoatsoftware.com/blog/teams-dont-need-to-think-of-everything-during-sprint-planning

Now to broaden the answer: you may find this whole thing very difficult because of the nature of your product backlog items. Let me be clear, you do not have to use user stories for Scrum (in fact, they are from XP and Scrum just says "Product Backlog Items") but the reason they have become so common is because of how well they work in Agile development.

Your backlog items are written like a Work Breakdown Structure. A WBS largely assumes a fixed end-scope, assumes complete knowledge before the beginning of the project, and focuses on labor over value. User Stories, on the other hand, focus on delivering a capability to some user of the system. For example:

As a customer, I would like to see what information is already in the system about me so that I can see if anything needs to be changed.

The tasks from this may be something like:

  • figure out API auth process
  • call api
  • design panel layout
  • populate panel
  • data quality check
  • ...

As you can, this user story cuts through a few of your user stories (though probably doesn't fully fulfill them) and also delivers a particular piece of functionality.

Again, Scrum doesn't say you have to do this. It just makes the whole process easier for most teams.


When is the best time for developers to break Stories down into Tasks?

The Scrum-team should be self-organising. After careful deliberate thought and experiments the team should come to a point in time that best fits their process. Therefor I suggest they experiment with different times and see which one nets the best results for the team. The retrospective could be a good meeting to discuss if the current way of breaking down stories is optimal.

Some common times:

  • During the Sprint at the start of the user-story. My current team does a "Architecture & Design" design discussion when someone starts on a new story. This short sessions (15-60 minutes) results in tasks so the developers can work in parallel and swarm. (I would prefer this)
  • During the planning session (earlier seems a waste, since there is a chance the story is never picked up in a Sprint). Do question if you need a detailed plan to forecast. Long planning meetings suck the life out of developers.
  • I disagree with your first two sentences. Formally, the Scrum Guide says, "The work to be performed in the Sprint is planned at the Sprint Planning...enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less." So the entire Sprint Backlog doesn't have to be decomposed during Sprint Planning, but especially for shorter Sprints that's typically the right ceremony.
    – Todd A. Jacobs
    Jun 21, 2017 at 23:38
  • You left out the next sentence of that quote: "The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint." The units of works could just be user-stories. Not detailed tasks. The team should self-organise and decide what they need. Jun 22, 2017 at 7:01
  • Also breaking stories down to tasks during the planning meeting sounds very dogmatic and hurtful. I wouldn't want to bore my P.O. with it, nor keep the developers in a meeting room for too long. Hearing teams splitting the Sprint planning in two meetings because of this makes me think that breaking down stories is something you do just in time. You don't need it to create your forecast and Sprint backlog. Jun 22, 2017 at 7:33
  • Please don't misunderstand me: I'm not saying all-or-nothing decomposition. I'm basically trying to address the mistaken "agile means do whatever you want" notion that a lot of people take away from these discussions. I know that's not what you're saying. I'm pointing out that your first two sentences make it sound that way to someone less attuned to the nuances. It's just feedback from someone who fights that viewpoint routinely in new implementations.
    – Todd A. Jacobs
    Jun 22, 2017 at 19:54

Maybe SAFe (Scaled Agile Framework) or leSS or Dad would be a good solution for your company? What they offer is a bridge between scrum teams and monolithic structures in a big company. See this: http://www.cio.com/article/2974436/agile-development/comparing-scaling-agile-frameworks.html and show it to your managers. For example in SAFe you work in 13 week Product Increments (divided to 2 weeks iterations) during which you are supposed to deliver an epic. The team (not a manager) plans it upfront for the whole PI and then adjusts accordingly during following iterations. It is not a pure Scrum nor a perfect solution but kind of reasonable compromise that might help you.


•101 get the customer info from API

This is not a good userstory. It does not provide any customer value but focusses on a technical step in the process.

These are better: •103 Let user pick the options they want •104 verify the user entered date •105 do not leave page until all required info provided

because you can deliver 103 without the verification, and do the verification of 105 manually, afterwards. You can put a single notice on the page 'make sure you always enter a date', thus satisfying 104.

Learn about storymapping. Make sure you deliver the process to the user, instead of pre-defining what the process should be, slicing it into steps, and delivering these as stories.

Read about storymapping.

  • I agree that 101 does not deliver obvious "customer value" but I do have a questions. 80% of the work does not provide "customer value", yet without things like loading the customer data from an API, there is no point in showing a screen, step 102. This leads to a different question ... How to show progress when 80% of the work is behind the scenes?
    – rwg
    Jul 10, 2017 at 16:04
  • This requires wrapping your head around 'value'. No customer ever asked you to load data from an API. Suppose you learn your app needs a 'HELP' function. The team debates whether this should be a manual or an FAQ. You decide on the manual and start writing it. You slice the work up in the 28 chapters the manual will contain. Now you have your work cut and sliced but you are not delivering value. But suppose that instead, you add a notice to the application: "For help, call 111-222-333 or email us at [email protected]'. Now customers can get help. You have provided value.
    – user24119
    Jul 24, 2017 at 13:59

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.