How to deal with tough story that carries 2 sprints

First, you are to be congratulated for providing some transparency over technical debt at all. Few teams and organizations are in a position to state how much they’ve got.

What you need to do now is to decide what your policy ought to be for paying technical debt off.

You might decide to pay it off over the next 3 sprints for example. In Product Backlog refinement, the estimates you give for those items which are likely to fill the next 3 sprints might then reasonably include the repayment of technical debt.

I get this question all the time. You can break it down you have to keep trying.

"PO cannot forecast based on unstable velocity like that." I have to say this to people all the time " Do Not! Try and normalize your estimates so you can try and have consistency from sprint to sprint. Each sprint is different each sprint delivers something different. No 2 sprints should be the same. 

Do you really want to see say 30 points from sprint to sprint over say 20 sprints? I know some orgs do because it makes them feel safe and that they are succeeding. I wont get into the weeds of why you should or shbould not would take a couple paragraphs and I have spent too much time on this board the last week or so.

As Ian stated technical debit is a policy change many techniques to pick it off. You guys have to meet and decide on that. 

Hi Vinh,

I have been a product owner for multiple product in the past years, and yes I recognize the situation you describe. 

First of all; in my experiences, chopping up user stories that do not fit in a single sprint usually seems to break the 'value' criterium in the INVEST mantra. From a business value perspective this is probably very true (functional or non-functional), however, sometimes when having a complex topic at hand, there are technical steps to take that bring value on its own. Value to the product, but not for users of the product. 

Now, this is a dangerous thing, because accepting this as a PO, could be accepting a kind of waterfall approach of delivering things. That's why I usually challenge the team a lot on these things. However, sometimes this is just very true. And then I suggest that the teams picks up a technical userstory first that reduces the risk of the overall solution the most. 

Secondly; a product owner who is using historic velocity within sprints as a mathematic precise project manager type, is not a product owner. Velocity of the team is of course useful for extrapolating when which userstories would be delivered in time, in a roadmap. However, velocity over past sprints should always be considered in context. Such as the situation you described. Or, for example, 2 persons ill. Or a training day. Or holiday season. Or the airconditioning broke down and everybody was continually getting icecreams next door. 

Last but not least, I fully agree with Ian, that identifying and acting upon technical debt as a team, is a level of maturity of the team that is something to be proud of :)

Either I don't fully understand the described scenario or, if I indeed do, I should have not experienced a similar one. And I've never came across a situation where the user stories can't be decomposed to much smaller chunks. If it's something too big, call it an epic and break it down in multiple units which can then subsequently be worked (refined) and selected for sprint coverage based on their priorities and the business appetite.

"How do you eat an elephant? One bite at a time."

Question: how long are the sprints? On the assumption they aren't just a week long (5 working days), I'd argue there's enough time to cover significant stories by a DoD and then release on a regular basis.

I would advise against implementing and testing in, as you say, 2 sprints, if these 2 take you above 1 month as the risks increase substantially. In fact, I would suggest you discuss with the team and explain why you need to find ways to cover small enough pieces to fit a single sprint and then have something Done that can immediately provide benefits once shipped to production.

One step further, the PO should understand (and then explain to board management) that velocity doesn't really mean much as it's not a productivity metric. Productivity comes from the value of the work the scrum team performed in a single sprint, work that is of Done quality and addresses business needs (whatever those are), prioritized at any point in time.

Forecasting is fine up to a point - but remember market conditions always change and there is always new stuff popping up. What I'm trying to say is, a forecast will only work if, and only if, there is nothing else new coming your way from the business (and added to the backlog) and there are no unknowns popping up from the work itself (the one you actually want to forecast). How often does that happen? :)

Really appreciated everyone for deeply thought and share your experience on this! I think I've got points to work with PO and team to resolve these current issues!