nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to deal with Big user stories

Vishal Vandre

Hello, We have 2 weeks Sprint. Some of the tickets that we pickup would take 2 weeks development work and 2 weeks for testing, hence QA testing moves to the next sprint.

Current process: I am the Scrum Master, who would create 2 user stories to avoid Spill over. I wanted to understand if this is correct or else there is better way of dealing with it.

Regards

Comments

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

The proper way to do this is to split the story into two or more stories that can be completed within a sprint, exactly as you say.

Jonathan V_

Hi Vishal, when looking at the aspect of not completing a task, I would agree with what has already been said regarding splitting the user story.

But, as a Scrum Master, I would normally spend some additional time to see if the stories can be re-written, breaking them down into smaller chunks of effort so that during a specified sprint you could complete both the development and the testing.

Keep in mind though, that this also depends on your organization's definition of done. If the organization considered something completed without testing, then in essence it might be ok to leave it as is without digging deeper (although I normally would still suggest to go a little deeper).

Hope this helps.

Nic Brough -Adaptavist-

Oh, absolutely. Splitting it into a dev story and a test story is a blunt and simple approach that kludges past this problem. Splitting the story up into several deliverable stories is by far the beter thing to do.

Jimmy Seddon

Hi @Vishal Vandre,

You have excellent answers already and those are the correct answers. I wanted to chime in here as I worked at a company that was trying to do things exactly as you have outlined.

As much as management "wanted" to be agile, everything kept reverting to waterfall. All the testing was backloaded as were the unit tests.

The mental shift that needs to happen is that you aren't "wasting" time testing each feature individually, that is a requirement to completing a single story, and if you can't break a story down, it means you need to look at it from a different perspective.

This change isn't going to happen over night, but I would strongly encourage you not to have separate stories for development and testing.

Thanks!

Vishal Vandre

Thank you! & point noted

Benzi

It seems you found already a good solution Vishal! Well Done!

There are many different ways to go about things like that. It depends on what works well for other team members & for you, as part of the team!

Here are a few options:

You could make use of various Issue Types in Jira: bug, (sub-)task, project task.
Perhaps you could use one of them to distinguish the development work that you can already expect to require more than usual investigative / preparatory work (like a "Spike").

You can also organize short-horizon user stories into an overarching structure for longer time-horizons, by using what Jira has to offer: Components, Epics/Features/Initiatives OR even assigning one "fixVersion" to each user story.

Lastly, as an alternative to the scrum approach, you can also consider using the more light-weight principles of Kanban, where the number of stories (Work In Progress) depend on the team size (which could vary over time) & their capacity. Team members themselves pull in work from the Backlog (of course depending on the priorities of the customer/Product Owner that are ordered from top to bottom in the Backlog and according to logical technical dependencies, if any). And they pull in this work onto the Kanban board once they have completed previous items.

With software engineering teams that collaborate well together naturally, I have found Kanban to be extremely effective, and it requires the least overhead.

For all teams it is useful to consider one thing: "Stop starting, start finishing".
Success with delivering value!

Welcome!

It looks like you're new here. Sign in or register to get started.