Hot answers tagged

22

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


15

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

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


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


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


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

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

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

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

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

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

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


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


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

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

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

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


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