The Stack Overflow podcast is back! Listen to an interview with our new CEO.
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

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


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


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

Great question, and a great problem to have :) If a team is ahead of schedule, it's still ultimately up to them as to how to manage their work. I suggest asking them what their stretch goal should be relative to the next highest-value yielding work in the product backlog, all while providing transparency to the PO. There's nothing that says you can't ...


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


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


4

What a wonderful problem to have - to be ahead of schedule. Besides for trying to get ahead on future tasks, I would suggest the following: Code reviews Adding comments to the code Updating specs to match to match the code Blackbox and whitebox testing of code Some fun activity; otherwise you may essentially be punishing the team for doing a great job by ...


4

Estimating using story points at the story level and time at the task level isn't necessary, but it can be useful, particularly for teams that are new to Scrum. Some reasons for using time-based task estimates include: The time-based estimates can act as a sanity check against your story point capacity If you have specialists in your team, you can check to ...


4

You are asking a question in good faith and the truth is story points may or may not help you. Like a lot of practices and patterns within the Agile ecosystem; it depends. Let's break your points down in order of importance. I know I have 13 people, 5 months and have to deliver X features. How would story points help me in this situation? I am really ...


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


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

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

To answer your first question re: the purpose of estimating effort in hours, it's really more complex than simply time/item. We're dealing with people here, and people have different skillsets, speeds, and knowledge. If you use hours, you obscure the main reason to use story points in the first place, which is to allow team members who perform at different ...


3

You should not do "agile" just because it's "agile". If in your current approach of "fixed price, fixed time and fixed scope" every party involved is happy, then don't change anything. I don't know where you get your time estimates from. Developers are notoriously bad at estimating time and story points are a way to make estimations better. But again, if ...


3

You re-estimate them. The difference is "lost", it's not part of this sprint's velocity, because it was not done. The re-estimated story can be in the next sprint, but does not have to be. You said "the testers were late". Does that mean testers are outside of your Scrum team? Then your Definition of Done is not working out. The development team should be ...


3

Is there an optimal workflow to still work with the DC and not leak money going back and forth discussing requirements and get a (mostly) accurate estimate in a short amount of time? Sadly, the answer to this is almost always "no". In software development there is inherent uncertainty. This arises from several factors, including: Requirements are often ...


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

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

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


2

@tiagoperes's Answer is good, but a radical change to suggest. To provide a less radical suggestion: have you looked at the cone of uncertainty? The idea behind the cone is that all estimates are ranges. The range starts out very wide but then narrows down as more information is gained (eventually becoming a point, once all uncertainty is gone - if you ...


2

Story points have a couple of advantages over time estimates. Firstly, people often find relative sizing of tasks easier than absolute estimating (e.g. this story is twice as big as this other story, rather than this story will take 3 days). Secondly, we use story points in conjunction with velocity, which is a measure of the rate of actual achieved ...


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


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