Complex user story that goes beyond a week

Sorry, correction to the post title, it should be "Complex user story that goes beyond a SPRINT".

Thank you.

I suggest implementing a spike into the sprint so the team can investigate this feature first; however, the spike should not be the only PBI in the sprint, as the sprint must still be able to deliver a usable and potentially releasable increment, even it the increment only contains one done PBI.  

Hi Scott, thank you, that's exactly what the team is doing now :)

But I am doubtful because I remember I read somewhere spike shouldn't be such a long activity?

I believe that it is supposed to be a time-boxed PBI within the sprint, say one day or so.  Hopefully someone more experienced will chime in shortly. 

It seems like there is an abundance of technical debt that is slowing the team down.

The first thing is that it seems like there aren't a lot of automated tests. I would recommend starting at the system/acceptance level or creating characterization tests. The team should be able to make changes with confidence that they aren't introducing unintended changes. Frequent delivery of working software requires rapid feedback loops, not just from stakeholders, but also your test suite.

If modifying an existing feature requires modifying code in multiple locations, that could also be indicative of poor design decisions. Having the tests described above would help support refactoring. It requires time, but spending the effort to make the code easier to work with will make future changes easier. Adding lower level tests, like integration and unit tests as you refactor with an eye toward testability and maintainability, will also support future changes.

It may not be possible in the current state of the system, but splitting a backlog item based on demonstrability rather than deliverability could be a viable option. Maybe the change cannot go to a live production environment without all of the pieces, but there may be ways to implement pieces and create demonstrations or deploy to a non-production environment to be able to get feedback on the work-in-progress. This can make sure that the team is going in the right direction before the deployment of the full change.

You can also consider other improvements for delivery within a Sprint. It sounds like your Sprint Goal shouldn't be centered around this piece of functionality at this time. Perhaps there are other improvements that you can make to the product that can be fully complete within a Sprint timebox and your goals can center on what is achievable. If that's not an option, the Sprint Goal doesn't necessarily need to be customer-facing. The team could make improvements to the product that improve their way of working as the Sprint Goal.

....... creating a valuable, useful increment every sprint.

I don't think the SG2020 says deliverable/releasable.

The important thing with technical debt is firstly stop creating it,  secondly know how much you've got, and thirdly have a policy for paying it back. 

Dealing with the first of these: in your situation, how would Developers actually know if they were to introduce more problems by changing existing code? Do they have a Definition of Done which is robust enough to assure the quality of the increment? This might be expected to include adequate test coverage for example.

@Thomas, Thank you so much for all your pointers. We don't have automated testing for this currently but we have full scenarios of what to test manually, so that helps in a certain way. As for refactoring the codes, it can be a risk that no one dares to take at the money because it's a critical system, so if anything breaks due to refactoring, it can create an even bigger problem altogether, though I totally understand that if refactoring is successful, it's a huge win for all future enhancements. The problem is I can't even split the story to something demonstrable because all the codes changes must be in place to deliver the single functionality change, else the functionality doesn't work or more accurately, work incorrectly. Eventually the code change might not be huge, but it's the effort to analyze and understand where to change that will take up most of the effort. Any other idea how to deal with this situation in terms of how to plan my user stories for upcoming sprint(s)?

@Nitin, I would reckon something "valuable and useful increment" is also something releasable and deliverable, no?



@Ian, yes, we try our best to reduce technical debts by not creating it but realistically, technical debt always exists due to various reasons. We now have full set of test scenarios to validate the behaviours of the program, so that helps in terms of the acceptance criteria. The issue that I face now is how could I plan the user story so that it can still fit in one sprint because it's not possible to split the single functionality change into two smaller user stories. Any suggestion?



 

I'd suggest that the issue you face right now is not one of story-splitting, but rather one of remediating technical debt. My advice is to focus on the three steps outlined. The outcomes to be obtained from Scrum do not arise from handling work items as if they were puzzle-pieces to fit in a Sprint.

You have made comments similar to this multiple times.

... how could I plan the user story so that it can still fit in one sprint...

Why are you the single individual of the Scrum Team that is responsible for solving that problem?  The Developers are the ones that have the most knowledge of the technical implementation and should be a driving factor in any splitting that occurs.  Ask them how to split the story in a way that enables them to deliver the requested functionality.  At the same time they can create stories to help them address the technical debt and add them to the Product Backlog so that they can be addressed over time.  The situation you describe indicates a large technical debt issue for this "critical system".  But if the Developers are not allowed or are unwilling to address the debt, it will always be an impediment to their ability to work in that portion of the code. As a Scrum Team, you need to recognize the impediment you are facing and take actions to remove it.  Even if those actions take many sprints to accomplish. 

Stop making excuses for why it can't be done and start making plans to do it.  Your Scrum Team should be empowered and enabled to make these decisions.  All of the advice you have gotten so far is good and can help your team become more productive in the long run.  But technical debt the size you describe did not happen in 2 weeks.  It took time to get to where you are and it will take time to get to a better place.  But denial that it exists and is a problem will ultimately cause you to fail.

@Kai

Not necessarily.

There could be a simple solution to your problem. Increase the sprint length to accommodate this. I don't see anywhere in SG that you can't change the sprint length once decided. Just don't make it a practice.

Thank you everyone, all points taken.