This is what the backlog is for. New requests get put on the backlog, and priorities can only change on iteration boundaries. An average of one week delay (half of a two-week sprint) is plenty agile enough to handle all but the most dire emergencies.

Here is how I dealt with a similar problem .. Back in the days when we were agile before Agile.

For any change request, the customer sets the priority. The developer can only, and must, stop work on a task to work on a higher priority task. Equal priority tasks are schedules in order of arrival. (Task Priority cannot be changed once work has started.)

It will hurt when you tell the customer that you cannot work on his task because you are working on unimportant task X that has the same priority as his latest request. You then tell him that at that priority level there are 50 trivial and unimportant tasks ahead of his latest request. Now the real catch – all these tasks are at priority level 1 (the Highest), set by … HIM … So he cannot bump you off the task you are doing. Now, when you have finished moving the window frame 3 pixels to the left to make room for the longer word in the Icelandic translation on the rarely used configuration option…..

I also close the door to the SD office, locked it and took the phones off the hook. Emails were ignored until at 10AM, 12PM and 2PM. Despite what people thought and felt, the world still went around the sun, we got our work done and the “Customers” got software delivered to them quicker and better than any time in the past.

It took a few weeks for the priorities to settle to something more realistic, we were able to unlock the door etc…. But the system remained for quite a long time. You may not need to be so extreme (we did), and will need support from Senior management. But it will work….

SOP. Standard Operating Procedure (or at least a loose protocol that is signed off by your management team). Your department needs to develop one, or work with your management team to develop one. The people you need to talk to are above the product-owner/account manager.

Some examples of what your SOP should define.

• What procedures are to be followed when a client or internal entity requests a change
• What are the implications and/or impact on the quality control or verification of this product?
• What is the method to reasonably determine a timeframe for delivery? This iteration? Next version?

Without such procedures in place, everyone is going to run at you like they are being chased by zombies and expect everything NOW NOW NOW. People like that won’t respect your polite ‘no’ or ‘please wait’s. With a firm policy in place, these code-craving mutants will understand that they are in the wrong when asking for things on such a loose basis.

The end result is unhappy you, and that isn’t in your companies best interest.

On a side note, you may have inherited someones mess caused by such blatant disrespect for his/her position and duty. People in that situation tend to find it hard to produce quality product. Is it any wonder? Software engineering 101.

It is very difficult to work under these “ready, fire, aim” conditions. It sounds to me like you are receiving requirements from a very insecure person, whose opinion changes each time a higher up person suggests a conceptual idea.

In these kinds of situations, I have found it valuable to wait AT LEAST an hour before responding to emails. (I’d ignore the texts, unless texting has widely replaced email by your organization as a whole.) Read them, maybe, but not respond. This way you can spend your time focusing on the actual work you need to do, not the discussion of random urgencies that may become irrelevant tomorrow, or even two or three emails later. In my last job, if something was REALLY urgent, someone would come over and talk to me in person, assuming I hadn’t seen the emails yet (if you work remotely, a phone call with an actual two-way conversation may be the equivalent).

When you have the face to face or phone conversation, it is helpful to repeat what the person is asking for in your own words, and then ask your questions about the new requirements and priority. “If I understand correctly, you’re saying we should stop working on Current Top priority X and now focus on Priority of the Minute Y. That’s a big shift. Can you explain the change in the business? I might need to do more background work than just changing the UI. Will there be changes in other business processes, like billing or inventory (for example)? Are you going to expect these new data elements to appear on all the monthly reports?” It is also useful to say something to the effect of ” You understand that if we proceed with this new effort, it will delay the release of Current Top priority X by at least a (week, month, fill in WAG time estimate here), right?”

If it’s a real emergency, the requestor should be able to answer these kinds of questions, or immediately refer you to someone who could. If it’s not a real emergency, this kind of conversation will force the requestor to slow down and determine how important the change really is, given that they need to get you more information. Often they’ll see that what’s already in the pipe is more important, or at least not worth stopping, and the new request can go on the list.

If the changes are determined to be necessary, I’ve found it useful to write down what was requested and your understanding of the changes in an email, and send it to the original requestor, asking if they agree on the scope of the change, again, as clarification. This way you have written documentation of what needs to be done, and why it was requested, in case there is any blow back on why you are no longer working on Current Top Priority X, or need to explain why the original deadlines are not going to be met.

This should hopefully improve your relationship with the requestor, since you are demonstrating your knowledge, and making sure that you are working on what they want, but you are being honest about what it takes to make changes. By asking about the request in detail, they see that you think ahead, and consider things they might not have originally.

It looks like nobody mentioned it yet, Sprint and its user stories ideally should be locked till the next sprint (typical sprint takes 2-4 weeks). By locking – i mean no additional tasks should be added into already started Sprint.

If user story is big enough not to fit to the sprint then brake it down to smaller, achievable tasks during the sprint. Also, as mentioned even prioritized tasks need to be hold in backlog, and during the next sprint planning high-priority once get the flag up 🙂

Edit: only minor changes can be introduced during the spring. if they carry emergency state. However, if there is always couple emergencies during the sprint, then something needs to be changes in Sprint planning itself.

Scrum has the Scrum Master role, which would be the person who should address the issues you mentioned.

If there is someone like a team lead, project manager, scrum master, etc. who is responsible, I would talk to that person.

I’ve tried explaining that there’s only so much time and that we
should focus on the most important things first, but something seems
to get lost in translation because the same thing happens a day or two
later.

I think that you will have to keep explaining that again and again and again. It sounds like you may need to accept that certain people you work with have unhelpful habits. If you are fortunate, you will see a change eventually.

Agile Manifesto says that one of the most fundamental principals is:

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

However, I don’t believe that they meant change on a daily basis. You might need to change the base price of a product many times a day, but not changing how that product might be sold many times a day. Rather the workflow of sales of a product might change on a week basis (in highly responsive and dynamic businesses).

Again, while workflow of sales of a product might change each week, I think the overall product won’t be changed each week. I can’t imagine a Microsoft which today gives us Office, but tomorrow will give us Offooose, and a week later Offasooooooooooos.

Nope, that’s not what agile means by change. I do believe that it comes from poor visions, and a big deep misunderstanding of the concept of change.

Let alone mentioning that change is not welcomed in a sprint, where developers go to their caves and do need to concentrate on what their doing. Rather, changes should be added to Product Backlog, and be analyzed and prioritized before they get delivered to the hands of the scrum team. In other words, a Sprint Backlog is not immutable. More agility should be sought using shorter sprints, not by injecting changed directly into developer rooms, many times a day.