9

Change Control Isn't an Agile Scoping Tool If he/she wishes to change the scope by adding in/taking out/re-prioritizing the Backlog the PO must submit a Formal Change Request/IOCA before taking an approved Change to the Scrum Master for Planning consideration. This is the antithesis of agility. While Scrum works just fine in environments that require ...


9

Retrospectives are a meeting for the Scrum Team and are internally focused. Sharing information from a retrospective with a wider audience has to be done very carefully. A couple of reasons for this are: People will tend to speak less freely if they know information is going to be shared outside of the retrospective meeting People outside of the Scrum Team ...


9

As Barnaby Golden has stated, it is not a good idea to share the content of a retro. It is very important for teams to know that the retro is a "safe place". What happens there, stays there - unless the team wants you to volunteer information about. But I wouldn't push them. Also note that not all teams are talking about impediments during their retros. Most ...


8

When projects and project managers are out of sync, this is an issue at the organizational level. The organization needs to resolve this problem if it chooses to advance in its project management maturity level. That said, it is quite common. Usually, you see this question from the PM point of view, who is trying to ensure its matrixed resources are ...


7

You should not reopen an old story. You should create a new one and if it is in any way connected to the old one, you could put a link to the old one in the new one. New requirements are completely new work and add new value to the Product, so definitely go with the new Story.


6

The following is pulled from a few different sources (including my own experience as a solo freelancer with multiple clients); however, you mentioned Agile and Scrum - so my terminology will be similar. Shorter development efforts, with extended silence: What I found worked for me was to have, essentially, a one week sprint. On Monday, you meet the ...


6

Issue Log & Risk Registry. (hat tip to @David Espina, without whose answer I would have missed this). You're responsible for your project(s). Anything that you can solve relative to those projects, you're obliged to solve. These are examples of things you cannot solve, because they are artifacts of dysfunctional organizational process assets. Things ...


6

Management by surprise. One thing you might try is each time your boss comes in with new urgent tasks you ask him: "Which of the tasks we have already agreed on should I drop in exchange for the new one?" https://www.vitalsmarts.com/crucialskills/2015/01/dealing-with-a-last-minute-boss/


6

TL;DR The original question was tagged Scrum, so my answer will focus on how Scrum expects routine and non-routine changes to be managed. In brief, Scrum embraces change, but encourages the Product Owner to plan refinements for future iterations whenever possible. By treating refinements as new work, the framework encourages ongoing collaboration between the ...


5

A common issue. There are a few approaches, but this is the one I use: Each change, or set of changes is captured in a new Change Request document. The CR document must capture the new requirements in as much detail as is required to a) approve them b) perform the functional requirements analysis c) do a reasonable estimate of the effort required to deploy ...


5

Yes, you do because otherwise nobody will be able to track the changes of the system, and know how your system is supposed to work. Make sure that you mark the change section in the history of the document.


5

From Agile Manifesto - "Responding to change" over sticking to a plan. It is a good practice to respond to a change so that your product/project evolve in right direction. It will lead to client's satisfaction. But there are some precautions you can take. 1. Please start writing the requirements in the form of Stories (As a user<>.. etc) and also with ...


5

I am assuming that this question is describing a "change" that is implemented bypassing a controlled change process. If true, then I would agree there is no such thing as a small, quick change. The issues of adopting the alternate point of view are many: Many small, quick changes equal a few large slow changes. The lengthy negotiations of what constitutes ...


4

It depends. If it's a change that affects the requirements, then yes, the document needs to be updated and versioned. But there are changes that don't affect the requirements. In that case, it might mean that the document has a hole and it should be added. Or it might mean that the change really doesn't affect the requirements and the document is fine. ...


4

Strictly speaking, the PO shouldn't be changing stories in the current sprint. For Scrum, best practice would be to abandon the entire sprint and start over with a new sprint planning session, new burndown etc. Other stories currently in progress can still be brought into the new sprint of course. As for timesheets - you should probably ask whoever ...


4

TL;DR You are missing processes, not tools. Specifically, you are missing a formal change-management process that handles your bugs, content updates, and other important tasks in a controlled fashion. Change Management At a basic level, change management can be thought of as a process for identifying, controlling, and tracking changes within a system. ...


4

Let them be emotional. You do risk losing your client because there are many in this game that give away stuff all the time but there are a ton of downstream threats caused by that that negatively impact both the client and the ones giving free stuff away. That said, if they find your work valuable, then likely it's just a tantrum to try to get their way....


4

My first step would be to ask how you are doing Kanban? Kanban is the go-to tool for rapidly changing requirements. The basic principle of "Have a board, have a WIP, prioritize daily", is incredibly simple. However, Kanban is really hard to do well. It's why I almost always start new teams with Scrum first, just so they can start to get the fundamentals of ...


4

I think the simple statement of your problem is that to plan you need to at least be able to count the number of things you need to do. However you have no base number right now besides the 800K & 50%. I also think you may be trying to apply project management to what sounds like process management. Maybe it's a little of both. I'm guessing. If you ...


4

I'd suggest to track and keep a complete end user documentation somewhere else (e.g. wiki, confluence - not a single document), perfectly versioned together with the system. A new user story needs a change in the code, test cases and docs. You can link it back but better link it to the docs. Initial docs are copy-pasted from the initial stories and then ...


4

TL;DR You have both a political problem and a process problem. There is no silver bullet, and you can't fix these problems solely within the team. Instead, you must rely on the agile concepts of transparency and visibility to ensure that the costs associated with bypassing the process are charged to the project budget. Make Costs Visible In agile ...


4

I agree with Todd about it being a political and process problem. I want to add that apart from showing them the impact on morale and quality -which I believe that they are quite important for your team- I would recommend having a discussion with them to understand why they believe it is useful to have this way of working and also prepare for them a "...


4

There are two views that may be helpful here. The first is that it is much easier to create change in a place where it is wanted than to try to force it. When I coach I rarely try to coach a team who isn't ready for it. Now, let's say you don't have a choice. There are a number of models for resistance to change you can look at. I personally like ...


4

By contact person I assume you mean project manager as that's the description you seem to be implying. The issue is not your customer or your vendor. The issue is your lack of knowledge and skills in managing projects, which is why you're here asking this question. The problem is, the forum cannot possibly teach you how to manage projects as you're missing, ...


4

I'm not sure I understand. It almost sounds like the example is using change management to avoid contractual consequences, which is not the intent. The job of the project manager is to estimate and communicate project completion date to the sponsor and relevant stakeholders. In your example, an issue caused the delivery date of a key component to slip. ...


4

A change process changes baseline values for scope, time, and cost, and for legitimate reasons. A variance on schedule is not a legitimate reason for a baseline change, generally speaking. It could be if the reasons for those variances were for external obstacles such as a hurricane that caused a stop work, or perhaps a legal issue. Being late because ...


3

TL;DR Your assumption that you need to track changes across multiple revisions is limiting your scope of change control options. So is your use of the Microsoft Word format. I'd reconsider both unless you can: ensure you have a single document owner, and track textual changes independently of your change-control approval process. However, if you can't ...


3

Defects are signals. Something is going on, which needs to be changed. Most probably you have some quality issues, and it is urgent to handle them as soon as possible. On the other hand, I suggest to talk to the Product Owner. She should be able to prioritise the user stories and bugs (you can handle bugs as user stories, but they don't hold any value). ...


3

TL; DR The Sprint Goal must not be changed during an iteration. Changes that would prevent the Scrum Team from reaching the Sprint Goal must terminate the sprint. The rest is just an accounting exercise that helps the organization understand the cost to the project for scope changes made mid-iteration. When Scope Changes Mid-Sprint Scope changes really ...


3

it sounds like you are unable to estimate prior to sprint planning or in sprint planning due to the large ambiguity of the requirement. You thus have one of two choices 1) Recognize the fact that the requirements are so ambiguous and that they are impossible to estimate. Thus the team will resolve these as they move along each sprint. i.e. stop ...


Only top voted, non community-wiki answers of a minimum length are eligible