Jira Sprint Structure for Software Team

Question

As I see it, we have three levels:

Epic - Broad view of what would be nice to do. (Usually more then a Sprint)

• Let pay for our service with credit cards

Story - More defined and structured view. (What can be done in a Sprint)

• Let people pay at website
• Let people pay at mobile app

Task - story that broken down to Components (Backend, DB, Frontend, iOS, etc) (What can be done in a day)

Let people pay at website

• Create a landing page
• Create REST service for payments*

Let people pay at mobile app

• Create a button in mobile app
• Create REST service for payments*

(* - same ticket)

There is a way to create an Epic in Jira. And we can add Stories to Epics. We can't break every Story to Tasks to have a nice structure. But as I understand, there's a common path. It's to create sub-tasks for Stories. What difference will it be from Tasks itself? And then we can take these Stories to our Sprint with a board's backlog spring-creating feature. BUT.

1. At the Planning, should we estimate Task or a Story? Every video that I've seen has estimated a Story. But how we can estimate Story by itself if it takes different components ie Database, Web Frontend, Mobile app? This is different people and different Tasks. Wouldn't it be more logical to estimate Tasks and then summarize their estimation for a Story?
2. If we creating sub-tasks to a story and taking whole Stories into our Sprint. What will happen if we will fail to complete whole Story to the end of the Sprint. Meaning, Story has 10 story point and equals three sub-tasks with 1,3,5 points. We closed two sub-tasks with 3 and 5. Will we be planning the next Sprint with a Story of 10 or 1 point?

Answer 1

A story should be deliverable on its own (when it's completed). It's best to stick to this as the convention all the time.

When it comes to Jira, any entry should either be a story or a bug. Anything that is not a bug is a story. As you pointed out, whenever other types are introduced, they only cause further confusion. We have been using this simplistic approach for quite a while and never had any issues with it. Obviously, Epics are still in use where multiple stories and/or bugs are involved that possibly span multiple sprints.

We have adapted the use of 3 levels as you said, the last one being subtasks. We create as many implementation subtasks as needed, but we also include all other actions that are included in our Definition of Done as subtasks as well. This way, when a story is closed, we are sure that DoD applies.

Regarding your questions:

1. Only estimate stories, never subtasks. It is perfectly fine for the team to come up with subtasks while discussing the estimation, however, they should provide their estimates as the team for the whole story considering everything involved in completing it in a releasable state. Members can share their thoughts on what's involved in different subtasks, but it's up to the team to agree on a shared estimate. Summing up the estimates for each subtask provided by different team members will not be the same (at least at the commitment level)

2. Use the remaining estimate. We prefer to estimate the remaining work in our sprint planning session and use that (1 point in your case). If you keep the original points, you will have to keep the amount of completed work in your mind, which is unnecessary baggage. Also, the purpose is to complete each story within the planned sprint, and the team gets better at doing this as they go along a couple of sprints together. The "lost" effort does not matter much as the important thing is the amount of working functionality you deliver.

Answer 2

What my team's done is use JIRA subtasks as tasks - the mechanical breakdown details of a Story.

JIRA 'Tasks', meanwhile, are on the same level as Stories, but are differentiated by the fact that they do not bring direct business value to any user. For example, 'optimize the compiler', 'research [new technology]', and 'increase test coverage' might all qualify as JIRA tasks. These, too, may have subtasks of their own.

Regarding your questions...

1. The estimation is done by the Team, representing the work of the Team. Not by individuals. This is part of the purpose of a cross-functional team and shared code ownership. People do not own Stories. The entire Team does.

2. My team has tried it both ways. First, we tried keeping the old estimate. Our reasoning was so that 'the knowledge of the effort we put into it wouldn't be lost'. Over time we discovered that no one really cared about that, and keeping around 10-point stories that had 30 minutes of work left in them was getting confusing. So in the end we decided to switch over, and it worked much better. This fits with the whole idea of Agile better, anyway; if you have more/better information regarding that estimate (the fact that it's 90% done) then why shouldn't you update it?