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


8

Agile Manifesto says that you should value Responding to Change over Following a Plan, however it doesn't mean that you should include every Change Request demanded by Client ASAP. Look at Scrum - you have Iterations and when you decide upon stories that would be acomplished during the Iteration the scope is frozen and you can prioritize tasks for the next ...


7

While not being a trained expert on the Agile ways, I would try to not bother the customer with uncertainty in the way of "you might not get what you asked for", but rather give him certainty that something (and be it just confirmation of the viability of a solution) can be done. I think agile methodologies can help here. Take Scrum. Your team should commit ...


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

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


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

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

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

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

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


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

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


3

Frustrating as it is you probably won't find a useful step-by-step guide that exactly meets your needs (I know this because when I first started out in PM I also wanted to find one). The truth is that every project is different and you will need to adapt your methodology to meets its needs. For example, whether you design, wireframe or develop first will be ...


3

I used to use a commuting analogy. You know it normally takes between about 40/45 minutes to get to work, so there's a basic level of uncertainty there: 40 to 45 minutes, but you don't know whether it'll be 40 minutes, 45 minutes, or somewhere in between. So you allow 45 minutes. But on a bad day (e.g. when the traffic is unusually heavy, or a train is ...


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

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


3

This is not "agile" project management. This is either a service department doing work as needed (e.g. an IT group supporting an existing application or legal department fielding questions on an as-come basis) or; this is a project without control and structure. The best way to maintain change requests is to formalize a submission/approval/status process. ...


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