Using Tasks vs Stories in some cases
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!
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
Sorry, to answer your question: A good practice is the epic/story/tasks model, where each story can be done in one sprint.
> 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.
Thank you all very much for your quick, clear and helpful replies!
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.
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.