Hot answers tagged

18

Can I add that to the sprint backlog as a new task ? Yes, you can add stories to a running sprint, if the team agrees to it. It's not a good practice though as it reduces the usefulness and predictive ability of the methodology. Some times the task's effort changes like earlier it was an 18 hr job now it's a 32 hr job This is relatively unimportant: ...


14

The Sprint backlog is a forecast, not a commitment In the 2011 revision of the Scrum Guide Jeff Sutherland and Ken Schwaber made an important change. They changed the word "commitment" to "forecast" in regard to the Sprint backlog. The term commitment has two bad consequences: The stakeholders expect to have every single item delivered at the end of the ...


13

From the Scrum Guide: During the Sprint: No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. The changes you mention fall into the last category, unless they endanger reaching the sprint goal. If the last ...


13

TL;DR Scope creep is a project risk, and must be controlled. However, in agile frameworks, scope is a variable constraint rather than a fixed one. To be an effective agilist, one needs to understand the differences between scope and change control, and how to properly apply a given agile framework to embrace change (which is a core value) without putting ...


11

I respectfully disagree with @DavidEspina. I don't think his answer is fundamentally wrong, but it doesn't match my answer. During project initiation (or in some contract work, prior to project initiation) you determine the scope of work. This is the box inside which all requirements must fit. The project sponsor and project management team must strongly ...


11

Just because you have 150 story points in your backlog now does not mean that work captures the work necessary from your stakeholders' perspectives. Every iteration, you should be evaluating what has been done and what remains, adjusting what remains. You may add work, remove work, or determine that there's no work left to do that's the cost of another ...


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

Product Specifications vs. Project Scope One assumes that you're not looking for dictionary definitions. We have Merriam-Webster and Wikipedia for that. For practical differences, I would suggest the following perspective: Requirements Requirements are the things your project needs built, and specifications are the instructions for what the things you want ...


9

Firm Fixed Price does not mean that the customer gets their desired solution for a fixed price. It means the customer agrees to negotiate about the scope and changes later and must pay extra for anything deemed to be excluded from the initial price. FFP can work as long as both customer and service provider understand the rules from the beginning and are ...


8

Project Scheduling isn't a science, but an art. So it's not enough to provide you with a simple equation - which I'm sure you could also do using a calculator - you also have to "understand" your project. E.g.: In your example case, one would need to know why iterations 4, 6 and 7 had low velocities. Was it because new team members were added and their ...


6

You don't need any of that; close your spreadsheets. You need a change management process which include a governing body. Scope changes via new requirements is the type of change that would go through this process. If approved, you get a new plan. You get to rebaseline. You get more money. You get more time. What you have now is scope creep. ...


6

Scope Should Never Change Within a Sprint We are currently working on a project were we receive a lot of change requests, and the client insists that we should deliver the changes in the current sprint itself! This is a sign that You Are Doing Scrum Wrong™. While there are certainly edge cases where stories can be added or removed from the Sprint, ...


6

If you had a scope change, a legitimate one that was approved via your change process, then you should also have a corresponding and proportional schedule and cost change. This means that the delay is not a delay but rather a new schedule target. Your first schedule baseline goes away as if it never existed. Same as your scope baseline and cost baseline. ...


6

This is not a matter of change request best practices, but a matter of contract negotiation and relationship with the customer. There is a reason why fixed-price contracts for developing software are just a ticking bomb waiting to explode; read for example Is Fixed-Price Software Development Unethical? There are a few things in the question that I want to ...


5

TL;DR I probably would have picked "C" as well, but can see what they were trying to get at with their selected answer. I don't agree with it, but I can see the point. It's an academic answer that probably aligns with something in the PMBOK, but that doesn't mean it's either a great question or a great answer. Ivory Tower Answers Most tests, and ...


5

So, there are a few things important to note. #1 - Assumptions - You assume one functionality takes 3-4 days to implement. Has this been confirmed with your team? Some tasks might be shorter (or even longer) depending on the work being done. One of the first things you should do is get with you team and get rough estimates (is this 1 hour, 1 day, 2 days) ...


5

Excellent question: To answer the question directly, yes, the developers can and should talk with the customer when possible. As you've pointed out though, the logistics of this can be difficult. Something that is rising in use, that directly addresses this, is the Product Owner Team (also known as the agile business team and the agile customer team). ...


5

As a Scrum Master I encourage team members to talk with the stakeholders. But I suggest they either do it in the presence of the Product Owner or brief the Product Owner as soon as possible after the conversation has finished. The Product Owner sees the big picture. What sounds like a perfectly reasonable request to a developer might actually be a bad idea ...


5

These are two judgement labels applied to the exact same behavior, based on the outcome. If you get it right, the customer is delighted. If you get it wrong, you gold plated and the customer is upset. I think the concept of gold plating in project management, and the teachings around the concept of avoidance, is based on the thought that the risk of ...


5

In Scrum, a project is done when the client tells you that the product you delivered is good enough or when they don't want the product anymore. That can be when all the tasks currently on the backlog have been completed, but it can also be earlier or later. If your organisation wants to hear a predicted end-date, you can calculate that based on the amount ...


5

This is not an issue of managing changes in scope, this is an issue of trust and respect. When two business parties trust and respect each other, they will usually find ways to collaborate and agree on things. When they don't trust and respect each other, they choose to sign contracts then argue and fight over contract clauses. Bring in the lawyers... You ...


4

I see two (or well, three, if getting a new job counts ;-) ) possible ways to deal with such situations in general: When you receive a refusal like above: ask for clarification or more explanation, open a discussion to understand the other party's view and to come to a common agreement based on facts instead of feelings. To avoid receiving refusals: make ...


4

You are right to be concerned about this. Vendor selection can be a significant drain on time and resources, so you need to either ensure that this is excluded from the scope, or that sufficient time is allowed to let the selection process run. I would start by stating a number of assumptions within your documentation, including the assumption that the ...


4

I am reading into this that the scope of the project and the firm fixed price are already negotiated and sealed. I can see why your customer thinks that vendor selection is part of the price because it is a logical predecessor to working with an external system. Since my hindsight vision is perfect, this should have been part of your price or excluded out ...


4

One of the four values of agile is "Customer Collaboration over Contract Negotiation." The first thing to ask is "what is best for the customer?". Once you've done that, then you ask "is it covered by the contract?" and only then do you delve into the "do we ask for more $". Specifically focusing on your issue the first question I'd ask is who was ...


4

I've been dealing a lot with a scope creep over the last 2 years. I created a list of things that is a must to keep in mind in order to minimize the negative impact on the project. At first - you should realize that scope creep will happen! You should: know the requirements; know the client's expectations; have balls to say "No". Saying "Yes" to placate ...


4

I usually answer by telling that the requirements need to be clearly defined before the project starts, and if there is any change during the project then it has to go through a change control process which involves the change control board, etc etc Your interviewers are right — this isn't agile. The point of agile is that requirements change. Your ...


4

TL;DR Whenever possible, think of epics as placeholders for more detailed product backlog items, not as evergreen stories. It's better to add new stories to the Product Backlog as they are discovered or requested, rather than invite scope creep by misusing epics as permanent Product Backlog work-generators. Deliver Stories, Not Epics In agile ...


4

If I understand your Question correctly, you're asking how best to approach agile development in a situation where there is a hard cap on time? The obvious answer is to constrain the scope. And a good technique to do that is to first develop towards a minimum viable product (MVP). You start out by getting from the customer a list of the absolutely must ...


4

It’s All About Expectations “Unapproved” doesn’t really capture the essence of scope creep. In purely pragmatic terms, scope creep is a slow or gradual increase in scope beyond the original plan. A scope gap (which is not really a very common term, in my personal business experience) is just the shortfall between stakeholder expectations of included scope ...


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