79

Is Planning Poker Bad for Software Development Teams? This is the wrong question to ask. Planning poker is a tool. Asking if planning poker is bad for software development teams is like asking if a screwdriver is bad for plumbers. If the tool fits the job then it's a good tool, if not, then it's not. The real question you should be asking yourself is: ...


33

With that much variation in the estimate, it seems like the work as it's currently defined is not ready for estimation yet. Based on that wide spread in estimates, I would say that the team doesn't have a clear understanding of what is required to complete the work. Unless the work was critical and must be started and get to done as quickly as possible, I ...


23

The first thing you should do is encourage the team to bring concrete arguments. "Things are more complicated than they seem" or "I dont think those complications are valid" are very vague arguments. "I disagree, because the database-adapter has 3.000 lines of code, so changes in this class are very hard" or "Finding all methods doing X takes a long time, ...


15

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


13

Vertical Slicing is a Best Practice, Not a Framework Requirement Your prerequisite tasks (by definition) must be prioritized over their dependencies, so a separate task or user story for C should be created to track it. The only reason this feels a little icky to you is that you're making at least one of the following implementation errors: Allowing your ...


12

Let's be serious, people don't usually care how you do 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 ...


11

Planning Poker isn't the only way to estimate and lots of teams get on well with other methods. More experienced teams may find they can reach a consensus estimate via a quick conversation instead. The idea of poker is that it encourages the whole team to contribute an estimate and that everyone's opinion is important. Averaging is reasonable if the ...


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

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


8

Some suggestions which could help, depending on the nature and size of the story. Arrange a code walkthrough so that the team members can see the issues for themselves If the story is small enough that some subset of the team are able to pick it up then maybe the team can come to an understanding that those people alone will work on this particular story ...


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


7

By estimating iteratively. Look into the cone of uncertainty. At the start of the project, the amount of uncertainty is high, and the cone wide. Thus, your estimate would be 'between 2 and 6 months'. Partway through, the uncertainty lessens and the cone thins. One month in, the cone becomes '3 to 4 months'. 3 months (12 weeks) in, it becomes '13-14 weeks'....


7

We estimate as a team and then take the average Good grief, don't take the average! That's not how planning poker is played. Here's how I teach my teams: start with a brief discussion of the work involved play round 1: everyone shows their card. then the highest vote and the lowest vote each explain their rationale. Perhaps further discussion ensues. ...


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


5

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


5

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


5

Introduction The goal of Planning Poker is to help the team right-size the amount of work pulled into the iteration. This avoids over-committing the team, and ensures sufficient slack within an iterative process. It is not intended to deliver high precision estimates, offer an iron-clad money-back guarantee, or target higher levels of team and individual ...


5

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


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


5

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


5

It seems that you are considering certain things to be immutable. Like having to always split stories vertically, or that there shoudn't be dependencies like C, or that once allocated story points can't be changed. These are not immutable. All the projects out there, all the products, all the features, and all the stories, will never fit entirely with all ...


4

Mike Cohn has a great article on Story Points. Some of the highlights are Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. ... Because story points represent the effort to develop a story, a team’s estimate must ...


4

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 that kind of logic (and with estimating in ...


4

A healthy conversation when estimating might go something like this: Developer: "This is pretty simple, so I think it is a 3 point story." QA: "I'm thinking about how we will test this story. It looks tricky to me." Developer: "Talk me through your thinking on this please." [technical discussion] Developer: "OK, now I understand the ...


4

Hard question; I'm skeptical that there is a truly good answer to the question. There are some approaches/opportunities Build in the confidence interval. "If I understand your requirements correctly, I'd estimate that it is 80% likely we'd be done in 4-10 weeks, with the most likely value being 9 weeks." Build in the rolling plan, "Based on what you've ...


4

It's no bad, and neither is stress, but since you're asking the question, it may be the source of a larger issue. I've been on teams where I've liked planning poker and teams where I've loathed planning poker, so I would say that generally "it's good", but in the wrong context, "sometimes it's bad". When I said it may be part of a larger issue, such as ...


4

I like to use the 1,2,3,5,7,10,20,30,50,70,100 sequence for story points. If the team members pick neighbors, i.e. 20 and 30, just take average of 25 and move on. If spread is higher, like 7-20 it usually means the scope of what is asked is unclear and team members are bidding on different scope, or some see difficulties others do not (either party may be ...


4

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


3

This is a tough question, and I've been in your position. Every single time, I was wrong in my estimation. There was some gotcha, or something I didn't know, or some event that caused us to be wrong -- terribly wrong in our estimation. It's not difficult to estimate small things; but it's impossible to estimate accurately even medium sized things; and the ...


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


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