New answers tagged

1

In your experience, how reliable is the velocity in letting the product owners forecast the delivery date of a product? Highly unreliable. This is as a result of: Discovery will occur as you progress towards release and even if velocity is spot-on, you will still have inaccuracy due to new requirements being added Change happens: teams change, people ...


1

I agree. "Velocity" is a metric that of course has no absolute standard. However: "within your project, and perhaps within your organization over time," things like these can maybe begin to acquire relative meaning, if you apply [more or less ...] consistent standards to a succession of projects.


3

How reliable is velocity? To give an analogy, it's just as reliable as the weather. Yesterday's weather, for example, is a Scrum pattern that helps teams quickly calculate how many story points they will likely manage to get done in the next Sprint. It relies on the idea that if you have a stable team and a stable working environment, what you will manage ...


2

Reliability and validity of estimates depend on what you define as an estimate. I am answering this question not from a Scrum perspective but rather generally regarding estimation. I unequivocally disagree with any "no estimate" point of view. The reliability and validity of an estimate will never be 100% perfect because it is a prediction of the future ...


0

You can't make estimates more precise by changing units to Story Points. When it comes to deliverables it doesn't matter in which units you estimate - you still want to predict the date. The idea of Story Points is not to predict precisely, it's the opposite - they imply low precision of estimates. The best solution here is not to estimate at all. When ...


3

In your experience, how reliable is the velocity in letting the product owners forecast the delivery date of a product? Not very. "Delivery date" is a vague concept. What, exactly, does it mean? Does it mean the delivery of the last item known to be necessary? Or does it mean the next releasable software increment? Some frameworks, like Scrum, call for an ...


0

A good rule of thumb is to drop the highest and lowest numbers and average the remaining. In your case you'd drop the 5 and one of the 16s and get a smoothed average velocity of 11.75, meaning you'll complete 150 more story points in about 13 more sprints. While the average is useful, I'd highly recommend communicating projections to your product owner in a ...


-1

With a highly interdependent system such as you describe, "stories" might not be sufficient either as a measuring tool or a task-layout tool. You need to incorporate an understanding ... no doubt provided by the experts in the team itself ... of how "stories" actually relate to the components of the underlying system. Because, "this is where the workers ...


0

Don't re-estimate the story points which have fallen out of the previous sprint, you're telling the team their commitment and points are not important and undermining the process. You need to get to the bottom of why. When you introduce this rule the team may say all the work is done which should lead to a conversation as to why the tasks were not fully ...


1

Things to bear in mind when you are asked when something will be "complete": The items at the bottom of the backlog are generally the least important, so knowing when they will be done is much less important than knowing when earlier items will be done. A healthy backlog grows - it doesn't just shrink. Being done is not in itself a desirable state to be in ...


0

Work out the average from your reliable sprints, try to remove outliers. Divide the 150/avg velocity Consider the uncertainty, ie does the team get disrupted, resources moved in or out. Based on the uncertainty adjust your estimate to add contingency between 0-25% Consideration: If you have historical data for the same team use this to see how many ...


0

Sounds to me like your team wants to work, but doesn't want to solve, to plan or to be held accountable. Fairly common in my experience, generally a reaction to the presumption that management will hold the team accountable for negative outcomes, but not for positive outcomes. . . . [there] is a combinatorial explosion in the way they can be used such ...


2

TL;DR To perform agile release planning, or to calculate the estimated number of Sprints needed to complete a set of items from the Product Backlog, requires you to calculate your team's velocity as a per-iteration value or range. That value/range is then used to determine how many complete iterations (rounded up) are likely to be needed. Calculate a ...


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


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


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

There are so many things happening here that if you try to enumerate them, you'll just get frustrated, as I suspect you already are. Let's start with a simple acknowledgement that your team is not, in any way, practicing Scrum. They may be doing great work, but they aren't even trying to use the Scrum Framework. This isn't meant as a judgement on the team, ...


6

The first step is to get any estimation to include the whole team. Rather than just the developers estimating development effort, the estimate should consist of the effort and complexity from the entire team needed to get it finished and through testing successfully. If you couple this with not reestimating and not getting any credit until the work is done, ...


1

In my team, we create a separate task, usually 2h, to research an issue that we don't know very well. With the information, you can give some insights to your team and make the first estimation. Those 2h of research are negotiated with the customer and are part of our Cooperation models, so the customer knows in advance that some tasks will require extra ...


Top 50 recent answers are included