I'm working on a team with 1 week sprints. We have a feature that provides a status indicator for a long running job processing up to thousands of files. There will be some development work to obtain the status of each file.

The product owner wants a graphical spinner showing progress of each file as it is processed.

The entire story was estimated to take almost all of one developer's time for the sprint.

Some people want the entire story to be one card and to eliminate the graphical spinner mid-sprint if it becomes too time-consuming to finish by the end of the week. Other people want two cards. One card covers the gathering of the status. The second card covers the graphical spinner.

I've always thought it made sense to keep cards as small as possible in order to avoid changing requirements mid-sprint.

Is it appropriate to split this story into two cards or is it better to keep it as one?

  • 1
    What's the Sprint Goal? Why did the team accept the story if it was potentially too big for the Sprint? There's a lot of context missing from your question.
    – Todd A. Jacobs
    Feb 24, 2016 at 6:16
  • A good practice is that a single story shouldn't exceed 1/3 of Sprint Capacity. While on the Sprint Planning meeting, did the team believe they can deliver it? If not, why they agreed to take into the Sprint Backlog? Feb 24, 2016 at 21:59
  • @CodeGnome: the story was added because it is considered the most important feature for this sprint. The question is about breaking out the minimum required features from the features that are nice to have. Feb 25, 2016 at 17:48

3 Answers 3


The entire story was estimated to take almost all of one developer's time for the sprint.

This means the story is too large to fit in a sprint. A story that takes the whole week to develop seems likely to require some significant testing. Development time plus testing is going to almost guarantee it does not get 'done' within the sprint.

You have three options:

Have more people work on the story

If it takes one developer a week to develop the story, would it take less time if two or more developers worked on it? Perhaps pairing would help to speed up delivery? Could automated tests be developed in parallel with the development to speed up testing?

Split the story up

In Scrum we typically avoid making changes mid-sprint as these can be disruptive and can also impact on the team's relationship with their stakeholders. It would be quite unusual to plan for a mid-sprint decision point, such as dropping the spinner as you mention.

Splitting the story is a definite option but you still want each story to deliver some business value. It is possible that you cannot split the story up and produce two or more smaller stories that all deliver value. The team should discuss this in detail and keep an open mind about what the smallest story is that can deliver at least some value.

For example, the first story could be to show a crude measure of progress, such as an indication when half the files have been completed. Then, a second story adds in a better measure of progress and perhaps a third story adds in the visual indicator showing which file is being worked on.

If you are able to split the stories up like this then you can bring the stories in to the sprint that you are confident of completing. But you can also have the other stories ready to go, sitting at the top of the backlog. If the work goes better than expected then you could potentially bring in one or more of the other stories. It is a better approach to start with what you are confident in completing and then add items in, rather than starting with what you are not confident in and then potentially dropping work from the sprint.

Accept that the story will take longer than a sprint

This is the least favoured option. The problem with this approach is that it masks the true progress of the team. Scrum works well because at the end of each sprint there is a clear idea of what is 'done' and on what progress has been made.


First, one cannot just change things in the middle of a sprint, because one of the key pillar of scrum is the fixed length and content. One cannot just decide not do a part of a committed user story. Second, I feel a bit of uncertainty in your text about how much time implementing a spinner takes. Third, usually it is a better practice to do the visuals first.

Based on these observations I'd rather check how your planning meeting goes than the number of tasks you create. I'm not sure about your role, but the Scrum Master should recommend to put more focus on customer experience and estimations (based on previous sprints).

Without the spinner your team loses an important UX feature and I believe it is better to create it first with a support of mocks so that the PO can check how it is going to look like - it is harder to get frontend accepted than backend.

If the team doesn't know how much time a user story takes, it makes sense either cut it into understandable pieces or do an investigation or prototype before the planning meeting so that they have better options during planning.

So, you have multiple user stories, like "show progress for processing one file", "process one file", "show progress for processing multiple files", and "process multiple files". These are easy to demo, and at least two of them should fit into a sprint. I like small deliverable user stories than several tasks, because they provide speed not small tasks.

Finally, work on your planning meeting; how you prepare, commit, and estimate for that week-long sprint.


Your Product Backlog is owned by the Product Owner. They are the last word on whatever is needed.

The Development Team are free to a) pitch the idiocy of any idea to the PO, and b) refuse to accept a backlog item if they think that it is too big.

While the PO might not physically work on the backlog items they are the only person accountable and responsable for the backlog and everyone's understanding of said backlog.

All your PBI's should represent usable functionality that can be Done by the end of the sprint.

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.