The Stack Overflow podcast is back! Listen to an interview with our new CEO.

Hot answers tagged

21

Let's start with obvious observation: the moment that we know least about a project is at its very beginning. Unfortunately, for fixed-priced projects it is also a moment when we usually requested to say how much it's going to cost, thus to estimate. In such situation I would focus more on improving estimate quality than on choosing this or that estimation ...


16

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


13

Fixed price contracts and ambiguous scope do not belong together ...ever. You cannot go down the path of even saying clearly what you will do because no one knows what needs to be done. You cannot plan to handle it with change requests because a CR is a change to scope...and you don't have any scope. This is a time and materials contract. This is not ...


13

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


12

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


11

By definition, what you are describing, is not a project at all - because it has no defined beginning and end: A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. ~ PMI There are, however, a few ways to turn this concept into a project(s). One would be to create a backlog of items from bug ...


11

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


10

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


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


8

Marketing materials like this is more of a 'you know when you see it.' The development of this type of deliverable is a back and forth process. You elicit what you can, you design and build, you test it, you go back and make changes. I would challenge you in the waste of time and money opinion. Doing it a more controlled way may save time and money, but ...


8

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


6

If you have to estimate without requirements, you need to be very clear in stating precisely what you will do for the fixed cost payment you will request. So rather than accepting "the job" (which is some loosey-goosey handwaving specification), you will list specific deliverables that you can accomplish. Make it very clear that the deliverables will only ...


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

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

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


5

Measure the work. As you point you work on a lot of different projects. Considering you gather relevant data on past projects you should be able to see some patterns, e.g. most of projects seems to work this way but there are non-standard cases which were driven by one thing or another. It is hard to answer what brings variability to your work, but you will ...


5

The scale of a project is determined in the first place by the scope of the project (both product and project scope), and derived from that also the number of resources that you will need, the time it will take, required quality, level of risk. And all of that has impact on the budget as well. So I wouldn't call the scale a constraint, but rather the result ...


5

Your scope statement or scoping document defines the perimeters of the project across a number of dimensions. It's typically used to support project effort evaluation and planning, as well as detailed requirements definition, so the idea is to define what will be done/delivered (and what won't be). What to include in a scoping document: Functional scope: ...


5

To me, this is a simple answer. It is a change, and it does not matter if it was predicted or not. The original requirements and scope were developed based on the earlier operating system. The scope to be delivered is on the earlier operating system. So if the customer wants the application on the new operating system, estimate the effort, price it, get ...


5

welcome to PMSE! Let's split your question into sub questions... Is estimating a project without basic requirements or user stories a good idea? No, it's not a good idea at all, but sometimes we have to dance to the music. My gut tells me that not having all requirements in advance creates too much risk. I personally want to know what "done" ...


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


4

Please don't try to specify everything using BDD. You'll end up with a horribly fine-grained backlog that takes ages to maintain and which will still bear no resemblance to the real project that emerges. Something I've done - and which works very well with BDD later on - is to look at the high-level capabilities which the system needs to provide. A ...


4

Yes, the flow is the same, because you're not talking about a change to the scope, or the cost, or the schedule, you're talking about change to the project. Change management (or control) deals with those three in that for every change, all three must be assessed for impact. "How does this change in scope affect my schedule? How does this this delay affect ...


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


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