Skip to main content

Using Tasks vs Stories in some cases

Last post 08:41 pm January 21, 2014 by Sandeep Kamat
6 replies
05:57 am January 20, 2014

Hi All,

I have started using Scrum recently and I would like to get some clarity on the following:

I understand the concept of a story (please correct me if I'm wrong), it really relates to a feature for the end user. For example, a client that withdraws money at the ATM. Now, in a software development, say, I want to do some modification to improve the performance of my backend. This would include:
1. Review some code
2. Edit/create documentation
3. Create the tests associated
4. Prepare a release
5. review
6. Release
etc.

My question is: In the example above, knowing that I might not complete the entirety of the tasks within 1 sprint, should I use a Task/subtask model or an epic/story/tasks model?

Thanks in advance for your clarification!


06:32 am January 20, 2014

Hi pascal,
welcome to the forum.
The idea of Scrum is delivering small pieces of value each sprint.
This helps you to gather feedback, improve transparency, inspect and adapt.
If you cannot complete a story within one sprint, it is a good practice to split it. This is a part of Backlog Refinement.
But be careful to split it into pieces of value. This means, if you only review some code in the first sprint, you might ask yourself: What value do I get from this?
Usually you would try to choose a small piece for which you can do all the tasks above including the release. This is often not easy, and it may even happen that you don't find a way to split the story like this and have to split it by tasks, but try to work with the team to find a way.
Best, Ludwig


06:35 am January 20, 2014

Sorry, to answer your question: A good practice is the epic/story/tasks model, where each story can be done in one sprint.


08:01 am January 20, 2014

> knowing that I might not complete the entirety
> of the tasks within 1 sprint, should I use a
> Task/subtask model or an epic/story/tasks model? 

The important thing is to have a Sprint Goal. Product Backlog Items should be selected, and tasks planned, in accordance with that Goal. Scrum is agnostic about the form PBI's take, but one convention is to have epics which are broken down into user stories, and which can then be inducted into a Sprint Backlog.

The Product Backlog, including any epics and stories on it, is owned and managed by the Product Owner. Tasks that are planned for those PBI's inducted into the current Sprint Backlog are owned and managed by the Development Team.


09:35 am January 20, 2014

Thank you all very much for your quick, clear and helpful replies!


09:57 am January 20, 2014

A story should be independent, negotiable, valuable, estimable, small and testable (INVEST) .

In this case I think you should find out the acceptance criteria that can also help you how to decompose the given story in more then one Sprint.


08:41 pm January 21, 2014


Ideally all your stories should reflect the INVEST property and also have a definition of done. In most cases your 1 and 3 would be part of definition of done. 2. could also be, but some projects I have worked on have also done this in subsequent sprints ( in case you have a shared tech writer). 4, 5, 6 again would depend on how frequently you release the code to production. I have worked in scrum project where this was done for every sprint ( in case of a small scrum team) and also on projects where (more then 15 scrum teams) the release activities were done after a series of development sprints.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.