I am in favor of locking down stories fairly quickly in their life cycle. Requirements should be set after less than a day’s worth of discussion in most cases. After that point, it’s up to the product owner to decide if those requirements are actually something they want. If they aren’t, cancel the story. If they are something they want or partly what they want, complete that story, and create a new story for the following changes.

When in doubt, fight for creating a new story. Constantly changing the requirements just keeps moving the goal posts for the developers. That isn’t fair to them, and it’s bad for morale.

I think it depends upon your environment and how the product owner(s) react to missed deadlines. Because ultimately, changing the requirements increases the chances of missed deadlines.

Our job as programmers is to build what the business needs. So it’s always appropriate to change the requirements of the user story based upon the business’ needs. It’s also appropriate to document the change(s) so that a postmortem review can identify those changes as a contributing factor.

The criteria to judge the change impact is the same criteria you use to estimate the user story in the first place. The developer working on that user story should understand the change and be able size the impact. If the new sizing increases the scope beyond the remainder of the sprint, then the modified user story should be broken down into smaller components. It’s the same process that’s used to size and manage user stories before they hit the product backlog.

So let’s go back to the environment. If the product owner can’t handle missed deadlines, then it’s better to cancel the work from them sprint and re-schedule. That becomes part of the change management conversation. If the product owner is okay with some slippage, then the developer works as much into that sprint as feasible, and either creates a new story for the next sprint with the remaining work or lets the existing story bleed over. The new | bleed-over decision is one for the team based upon what works best for managing estimates.

But our job is to build what the business needs. Change is good. It keeps us employed. And it gets the business what they need.

Another question we might ask ourselves is: what constitutes a good user story?

Scrum Breakfast: Getting to Good User Stories suggests that a good user story answers the three questions of Who? What? and Why? and that it can submitted to a team in any order; that it will be easy to estimate, is small, and testable.

User stories that are too vague need more design time and usually end up wasting valuable sprint time. One of the attributes of a professional programmer is the ability to be honest with management. Many times this means that we need to be brave enough make sure difficult discussions happen when a story is not quite ready for implementation, because once it is ready, we’ll be able to accurately estimate when it can be done. We’ll then be comfortable making a firm commitment as to when we will deliver.

Attempting to estimate for a story that has too many unknowns will ultimately hurt your relationship with your managers, because, how can you deliver what they want when they can’t even fully define it yet. Stories like this usually need more design time. Allowing for design time during a sprint can help, but that’s only a first step. Design is not delivery. Until you have a story you can deliver, we must stay at the drawing board.

From the agile manifesto: “Customer collaboration over contract negotiation”

If you consider a story as a contract you committed to at the beginning of the sprint, you can’t change much without renegotiating your commitment. But I think that’s the wrong approach.

It’s fast and cheap to ask for a reestimate of the new story content at any time. Did the estimate (remaining work) change? Then you’re good to go. Otherwise, sprint planning might need adjustment – and as long as anyone is clear about it, it shouldn’t be an issue.