Allocating partially a story to a sprint

[Mathieu_]

Hi,

First of all I know that the situation I'm going to describe is not Agile/Scrum-compliant, but I'd like to gather some input regarding the situation I'm asked to implement in Jira.

Currently our teams do not work in Jira, we're right into design phase of the tool.

Method-wise, we plan to use stories as a "container" for all subtasks for a given team instead of describing a small piece of work.

I.e for one feature we wish to implement (epic), there will be several stories (let's say one for UX, one for back-end, one for integration, etc.), each story containing various subtasks.

For each epic, a rough estimate is made for each of these stories regarding time required for implementation : let's say 2 man-days for UX, 5 for backend and 1 for integration.

However, the size of these features is very variable and we already know that some stories will not be doable in a single sprint.

End users would for example like to allocate for example 20 man-days of a given story on Sprint 1, and another 10 man-days on Sprint 2.

My position was to split stories in two, but the problem is that at this stage, the story will already be composed of its sub-tasks, without any indication of order/priority.

Product Owner sole action is to allocate N man-days of the story for the sprint - he lets the developer choose how he will organize his work among all subtasks identified.

So at that stage, there is no way the Product Owner can split the story in two in Jira and dispatch subtasks between both stories as he has no clue how the developer will proceed.

I know that our process is not typical, but this is how things work currently (out of Jira) and users seem to be quite okay with current method, so I guess I need to try to find a workaround with Jira itself.

Any help/suggestion - either tool-wise or method-wise - on how I can manage this situation will be much appreciated.

[Mathieu_]

Hi and sorry for my late reply - I've been thinking to something else during my holidays.

Thanks Nic and Bill for your answers.

[Bill Sheboy]

Hi @Mathieu_  -- Welcome to the Atlassian Community!

I wonder how you are using the estimates and Scrum board-level of JIRA reporting for the methods you have described.  If the estimates are only for planning purposes, as a result of work carry-over between sprints and work items defined as UX, BE Dev, Integration, etc., please consider if Scrum is a good fit for your needs.

An alternative would be to use a Kanban board, limit your work in progress, and limit the selection of new work to the team capacity and PO prioritization.  That may be a better fit with how the team is working as described today, and eliminate the need to artificially split items that don't "fit" in a sprint's time-frame/capacity.

Please consider that JIRA is just a tool, trying to support how you work.  There is no need to change how you work to fit how the tool functions.

Best regards,

Bill

[Nic Brough -Adaptavist-]

If you're going to do this in Jira, I'd move everything up a level.  Some of your stories (the ones that are probably going to be too big for a sprint, even if you're not going to use sprints) are probably good candidates to be turned into Epics, with many of the sub-tasks being dragged up to story level when you do that.

That would enable you to do a proper granular estimation at the right level, and then allow the PO to prioritise the things that need doing properly.