Project Management Central

Please login or join to subscribe to this thread

Practice Areas: Agile, Scope Management
How to manage a project/sprint in a situation when client/management put pressure to accept stories even when a sprint is about to finish?

Situation when you are working with a rapidly changing environment - organization structure and strategies is changing, priorities of different clients need to managed in a single sprint, resources/team is also not consistent.
Sort By:

Perhaps I did not understand you, but it is not a problem to accept things when the spint is in process. No matter the environment is changing you have to put clear the change process. And change process is not about to have a full book is about to have a piece of paper with the basic steps to follow and mainly the process to decide and agree about the change.

Change is not necessarily a bad thing. If a potential change comes in, as long as there is sufficient analysis to assess the impact, risks, priority, a proper decision can be made - whether to incorporate now, or in a later phase. With the decision made, follow the change management process.

We need to accept customer requests on new changes as part of agile process...
At the same time, the following points to be considered and educate client....
A. Impact of current spirit and subsequent spirits
B. Project type - fixed cost or time and material basis
C. Business value
D. Changes type - minor,major
E. Project schedule impact

Muralikesavan nailed it. Working in agile, we listen to the change. We validate their requests. That doesn't mean it will get done right at that time. But we make sure the customer knows that we heard them. We build a tasks and as a project team, we determine when we can fit that change in to our plan. Does it get done in the current sprint (minor changes can and my team can help determine that)? Or do we do it as the next sprint? Or maybe when we are done with the project, we circle back for another phase?

If the client is not coversant with Change Management Process, it is necessary for us to educate the client during project kick-off or during meeting which has all necessary stakeholders from client side & senior management from your company at beginning of the project.
I work in industry, where customers don't follow or know about project management / inclined towards process orientiation and they tend to pressure PMs with new requirements during project execution. It goes to extent of them calling company's Senior Management to get work done. As PM, I would abide by PM practise and knowledge to educate both internal and external stakeholders consequence of CRs, which can drastic impact of schedule, cost , quality

First, you should always educate the client and manager of the consequences of such changes. like impact on budget, time, quality, resources, etc. All this communication should be documented in form of MoM or mails.

Second, still if client and management put pressure to accept it, put the identified impact points into risk register and sought out a mitigation or avoidance plan with the management. Communicate this too to the client so they are aware about the impact clearly now. Again have a documented communication via MoM or Mails.

Everyone has it covered, i just wanted to add one more thing. Have you considered maybe your sprint may be too long. Agile is supposed to remove the pitfalls that plagued water fall and if you are doing it correctly, is your client bringing something from the sprint backlog into the sprint goal?

I haven't been involved in software development, but from taking classes years ago, the goal of a sprint meeting is to have "A sprint goal and sprint backlog". Now if we have a sprint goal, except if something comes up that wouldn't let us meet the goal, we add it to our next sprint. Everyone involved should be aware of this already.

"Situation when you are working with a rapidly changing environment - organization structure and strategies is changing, priorities of different clients need to managed in a single sprint, resources/team is also not consistent." - is exactly why Agile/Scrum was developed to get over the very formalized water fall way of software development.

If this is a one time situation, you've received some good feedback, so far. If this is happening every sprint, Edward asks a good question - are your sprints too long? The next question is, "Does your leadership understand your company's agile processes?" Is this a learning opportunity where, by educating the people who are disrupting the process, you gain people who can better support it?

You may still have disruptions. Change happens, constantly. Scrum allows for this, even though it is not ideal. If work is critical and cannot go into the product backlog and wait for the next sprint, then it needs to be acceptable to stop the current sprint and plan a new one to address the new work.

Obviously, you don't want to do this in every sprint - velocity and cadence will go out the window. This is why I'm suggesting that you start with determining whether it is a process issue or a training issue. Once you understand the reason for the disruption, you can work on how to address it.

Case in point. I was assigned to a team that has a lot of disruptions. After a few months, we changed from a scrum-like process to something more like Kanban. My product owners are better able to focus on getting a few stories ready so that the developers can maintain their WIP. The impact of changing priorities is minimized.

Thank you all for your inputs.

Please login or join to reply

Content ID:

"Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened."

- Winston Churchill