Our stories are too big for one sprint, what is the right thing to do

[elramr]

Hi,

When our Product Manager opens a story, a lot of time the story will take more than one sprint work (our sprint takes 2 weeks) so when we will open sub-tasks for the story we will open sub-tasks that we know that we can only go to work on them in the next sprint, but because the relationship between story and sub-task they will wait in the current sprint and just when we will finish the sprint they will move to the next sprint and we start the work on them.

I know the right way is to try to make the stories in the size of one sprint.
But the Product Manager’s saying that even if this story takes more than one sprint, it feels unnecessary to them to break it down to the size of one sprint and they say there is no benefit for them.

Then we have a situation, where we receive stories that we know will take us more than one sprint of work and we have sub-tasks for the story that will drag on for several sprints,

I would be happy to advice

[Bill Sheboy · Accepted solution]

Hi @elramr 

Have you considered having a conversation with your Product Manager to explain "what's in it for them" with smaller work items, particularly when a team uses the Scrum Framework?  Your scrum master or agile coach can help with that discussion. 

Some things to cover could be:

• ask the Product Manager what problem they are trying to solve by not splitting larger items
• smaller, valuable items usually have less variability and uncertainty of scope, and so can be completed faster, and with less rework due to changes/errors
• smaller items usually can be finished within the scope of a sprint
• finishing items faster can speed the time-to-market and the time-to-learn what is valuable to your customers, perhaps faster than your competitors
• and because of the above things, the team will improve their consistency of delivery and find more ways to improve work methods.
• Together these things will make it easier for the team and the Product Manager to forecast delivery, and to better balance what valuable things to deliver next, and when.

Kind regards,
Bill

[elramr]

Thank you Bill for the information, I will try it!

[Nic Brough -Adaptavist- · Accepted solution]

The simple answer is that your product manager is wrong.

You should break down your stories into pieces of work that fit within a sprint, whatever the product manager thinks suits them.  The stories are for the developers, not the product manager.  If there are stories created that are larger than a sprint, then break them up, but group them together with an Epic.  Sub-tasks are not the way to handle this.

The other thing you could do is lengthen your sprints so that they can contain larger stories, but bear in mind that this will make you less and less agile as you increase the length.

[elramr]

I will try to talk with the product manager, Thanks for the help!

[Gupta Vishal]

Hi @elramr 

If you use Epic instead of big story and underneath that epic break actual story into multiple pieces in the form of issue type.

It will help you to do things faster and for forecasting your epic progress there are two agile report

1) Epic burndown= it will gave you how many sprints more needed to complete the work.

2) Epic report= it will gave you full report of that epic.

[elramr]

Hi Vishal, I’m not sure I understood your suggestion, right now we work with epics but also with big stories that take more than a sprint.