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.
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.