Scrum. Dealing with low prioritized stories that will introduce architecture change.

Question

Hi all, today in the university we had a Scrum practicing exercise (simulating the whole process of creating a software solution) and I came up with an issue that couldn't quite understand.

Let's say we've had defined our stories and give them a proper prioritization. And there is a story with very little priority... it's going to be done in on of the last sprints, maybe.

The problem is, what if this story introduces a huge architecture change to our solution's design? For example from stand-alone application, you will have to go for client-server architecture, because of this story only.

In my point of view: isn't it natural to mark somehow which stories are for certain to be done (in some particular moment of time), those that a critical to be done, but it's not critical when, so the team to have them in mind and make better decisions designing his solution. Or how are you dealing with this problem? If it is a problem.

Thanks in advance! And excuse my probably lame question.

Answer 1

in the real world with $$$ on the line, things that get low priority will probably never be done. And if they have a high risk factor which in the real world means even more $$$ at risk and low priority, they won't get done for sure. In your case if you know it will get done for sure then in your design sessions just make sure your designs will accommodate the needed changes easily with as little effort as possible on the current story.

Answer 2

If it must be done and it is going to involve large architectural change then it probably shouldn't be low priority.

The only time I can see that it should be classified as low priority is if it is acceptable to either drop it entirely or it's acceptable to hold off on it even if it'll cost a lot more down the road (say the product needs to get done and out the door so there can be more funding for it later down the road)

Answer 3

Because you said:

done in on of the last sprints, maybe.

I tend to agree with fuzzy lollipop (and +1 from me).

However, if there is something that you know will have to be done, but it's been placed toward the very end, it's simply in the wrong place if it might have a major architectural impact.

You can split the task into analysis and implementation, with (impact) analysis to happen very early to determine if there really will be architectural impact, and then implementation scheduled appropriately depending on the result of analysis.

Answer 4

This appears to be a Last Responsible Moment question.

If everyone involved is positive that this is a requirement, and it will affect architecture, putting it in the last sprint is unwise.

A more likely case is that it may be required. If you adjust your design to accommodate it early, you're maintaining that complexity through multiple sprints to support a feature that may never be added. (Business requirements change.)

With a flexible, decoupled design (such as one evolved via TDD), it's possible to keep the cost of change over time relatively flat.

Answer 5

The problem is, what if this story introduces a huge architecture change to our solution? For example from stand-alone application, you will have to go to client-server architecture, because of this story only.

I do not think that your example is realistic, such a feature must be somehow part of the product vision, you can't discover such a change in the last less important story, it must be taken into account at some point before the last sprint and last story. In other words, I agree with @fuzzy and @Eric here:

• If the story is not important and is risky, it will very likely never be implemented.
• If the story is important and is risky, it's very likely not so low priority (i.e. wrongly prioritized).

Answer 6

While priority is mainly a function of customer's desire, that isn't completely the case. There can be some technical aspects that are items the team determines have to be done earlier. For example, selecting an ORM may mean little the customer but it can be an important design decision from the team's perspective.

We have had these things pop up a few times in my current project involving a CMS where things like internationalization had to be addressed early but this wasn't necessarily a wise move as there were changes later such as bringing in another company's software to handle some of the translation which may impact some of our code.

EDIT: The Technical Debt Quadrant may also be useful for looking into these kinds of risks to see what you may be getting into if it is deliberate to get the big hit of debt at the end.