Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
Using Tasks vs Stories in some cases
Last Post 21 Jan 2014 07:41 PM by Sandeep Kamat. 6 Replies.
Most Recent First
You are not authorized to post a reply.
20 Jan 2014 04:57 AM
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
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!
20 Jan 2014 05:32 AM
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.
20 Jan 2014 05:35 AM
Sorry, to answer your question: A good practice is the epic/story/tasks model, where each story can be done in one sprint.
20 Jan 2014 07:01 AM
> 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.
20 Jan 2014 08:35 AM
Thank you all very much for your quick, clear and helpful replies!
20 Jan 2014 08:57 AM
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.
21 Jan 2014 07:41 PM
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.
You are not authorized to post a reply.