53

If at all possible, they don't. They ask developers to estimate it. Estimates should always be made by the people who will perform the work being estimated. If this is not done, then you run the following two risks: The estimate is inaccurate, as the person who estimated it did not have the knowledge of what work needed to be done The people who do the ...


11

Have Task Performers Provide Estimates In agile frameworks (and even in sensible non-agile frameworks), project managers should never estimate work items themselves. Instead, the people who will actually do the work ("task performers") do the estimation! To get the most realistic estimates, have the task performers estimate the time and complexity of the ...


9

The official answer to the problem is: There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to. However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your ...


8

What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional. Honesty is the best. You don't necessarily need to mention vacation, but being up front that, due to circumstances, the work will not be completed as originally ...


8

It is very rare that this is possible. But it can happen, so let's look at it: Any estimate is based off of statistical evidence from past experiences doing similar work. If the work we are doing is remarkably similar and we have a large set of data to work from, we can make estimates largely from categorizing the task. For example, I used to work in a data ...


6

A short answer to start with. If you have the Product Owner available with a well-defined list of Acceptance Criteria against User Stories, your agile team can conduct an effective Story Sizing session. Agile estimation (specially the Story Points estimation technique) is based on relative sizing. You need don't need to have 100% clarity to estimate ...


6

In terms of how to do better next time: It sounds as if you identified the risk as one of medium risk (might be ready) and high severity (huge business value), and you decided to monitor the risk (communicated with him on a daily basis and the progress seemed satisfactory). Monitoring the risk basically left you in a situation of "success-oriented ...


6

Story points are a relative measure of effort rather than an absolute one. However, each member of the team should have the same understanding of the size of a points estimate. A common understanding is achieved when the team estimates repeatedly together and when they agree common baseline stories against which to measure. This is really no different to ...


5

You are entering dangerous territory here. Why? Because programming is an art. If you start measuring things like lines of code written then instead of writing clever code, they will write verbose code. If you start measuring things like tasks finished then they will finish lots of tasks, but ignore quality, like implementing corner cases. If you start ...


5

Ask the person asking you. This advice applies in general - whenever someone uses a term with which you are unfamiliar, ask them what it means. This carries a slight risk of making you seem ignorant. Which is far better than the large risk involved when making an incorrect assumption, which can end up being costly to the project. Not to mention, it's ...


5

I know of at least two "Empirical assessment of machine learning models for agile software development effort estimation using story points". Available online at https://link.springer.com/article/10.1007/s11334-017-0288-z "Empirical Validation of Neural Network Models for Agile Software Effort Estimation based on Story Points". Available online at https://...


4

TL;DR There's no single formula for determining how many tests a set of specifications will require. However, you can estimate level-of-effort and set quality targets based on your test plans, provided the people making the estimates are the ones who will be doing the actual work. The Testing Pyramid and Its Effects on the "Iron Triangle" There is no ...


4

No team I ever met was self-motivated to fill out bureaucracy tickets. The question you should ask is: who wants them to count hours and why. Then find out how to solve that need. Ideally, you have a capacity for each team member and that capacity goes down when you have meetings. A person there for 8 hours per day might only have 6 hours of capacity. ...


4

Let's be serious, people don't usually care about estimates. What they care about is how much it takes and/or how much it costs. Time and money. That's what they want. The estimates is just something that helps you answer those questions. It doesn't matter what you use for estimations as long as people can get back a time or money value. It can be estimating ...


3

Imagine you want to maximize the team effectivity by minimizing down-times of each guild. Trying to get more work out of a team by minimizing down-time is called the resource utilization trap. Here is a nice video showing how minimizing down time does not actually increase the output of the team. The target of a sprint should not be that everybody was ...


3

Agile teams look at project work as an assignment to the collective team. Rather than working in the units of time it will take to finish each piece of work, they think about the amount of effort that will be required to complete the work, and the complexity and amount of sustained concentration it will take to produce it in a finished, tested, and ...


3

As a former developer and agile pm, here's my 2p. Some tasks are easy to estimate as they're a known quantity and have been done lots of times before. A sausage factory knows exactly how long it takes to make one more sausage. Some tasks are impossible to estimate. A biotech company doesn't know if it will ever find a cure for disease x [insert some ...


3

It depends on how you are using your estimates. If your estimates are measuring the work delivered in a sprint then it makes sense to estimate the bugs. If, however, you are using estimates to measure the team's ability to deliver completed, valuable functionality, then it makes sense to not include the estimate for carried over bugs. Mike Cohn explains ...


3

1) What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional In fact I agree to Thomas' "Honesty is Best" approach. Having another developer assigned to the task will definitely not align with the budget and I suppose that this ...


3

Velocity was never intended as a performance measure. It is designed specifically to help teams to estimate their capacity in future sprints. If it is being used to criticise the performance of teams then you have a problem. What this highlights is not that there is an issue with the Fibonacci scale, but how important it is that everyone involved is ...


3

The Scrum Guide states that: Product Backlog items have the attributes of a description, order, estimate, and value. Note that Scrum does not define the units for an estimate (Story Points, calendar hours, ideal hours, or something else). It also doesn't say that the estimate needs to be numerical. The purpose of the estimate on the Product Backlog Item ...


3

I'm a little bit worried about the way you phrased your question. From what I gather, you want some sort of formula or process to account for the risks, then use that formula to get the perfect estimate that will in turn protect you from those risks? Something like this doesn't exist. There are a few problems with logic like this (and with estimating in ...


3

TL;DR A research spike is intended to reduce the cone of uncertainty for future work. It is not intended to deliver shippable increments of anything. Treating the output of a spike as anything other than input to story planning/refinement is a Scrum implementation smell. Time-Box Your Spikes As an empirical control framework, Scrum is heavily reliant on ...


3

There are a few things to consider. Regarding "constant pace", the Manifest for Agile Software Development says: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This does not say anything about the complexity of work increasing or decreasing over time. It also ...


3

Each person in a team may have his personal understanding of the correlation between an effort and Story Points. Initially, in a new team, that may be true. That is why an estimation based on Story Points is more than each team member just giving a number and then taking the lowest/highest/average/whatever as the final estimate. When doing a Story Point ...


2

Scrum is a balancing act between: Preparing user stories so that the team can effectively work on them in sprints Not doing too much up front work so that you are able to respond to change. Every team needs to find the right balance point that suits their organisation and way of working. If you spend time producing test cases on stories in the backlog ...


2

If you see little value from estimating project duration then don't bother with it. However, there may be some value in measuring the time it takes for tasks to pass through the workflow. One of the Kanban principles is to look at cycle time and use it to help analyse process improvements. For example, you might try and put a work in progress limit on one ...


2

The official answer from the guide is: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum ...


2

Estimates should be based on effort. Complexity tends to increase the effort needed. Ambiguity serves to widen the cone of uncertainty of an estimate, which correspondingly increases the estimate because when providing a single-value estimate, you generally want to be estimating on the upper side of the cone. But at the end of the day, estimates are ...


2

Is this mandatory? In Scrum terms, no, this is not mandatory. There is nothing in the Scrum guide that requires stakeholders to state their availability. However, there is definitely value in explaining to the stakeholders what their role will be and getting a commitment from them to support the Scrum team. How can I estimate a client’s availability? I ...


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