81
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:
...
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 ...
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 ...
30
TL; DR
Agile release planning is based on fixed-length, normed-capacity cycles that operate on dynamically-planned and dynamically-scoped features. In Scrum, fixed-date release planning must be handled by controlling scope to meet the deadlines, as you cannot have both fixed-date and fixed-scope deadlines simultaneously. This is rarely a practical problem, ...
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, ...
21
TL;DR
Should velocity increase with time?
The simplistic answer is that a project's velocity should only increase until the team has developed a stable, predictable cadence that can be maintained over time. There are a few caveats, of course, but it's a solid rule of thumb.
Targeting an indefinite upward trend on velocity is a "project smell" that the ...
20
When estimating user stories, everyone should be estimating the complete effort it will take the team to get the story to Done. So, the back-end dev should not just estimate the effort it will take him to do his part, but his estimate must also include the effort for the front-end, the design and all testing (and similar for the other team members).
The ...
19
TL;DR
Neither of your stated options are truly agile. You are misusing points in an attempt to represent progress or to "hold people accountable." Neither is appropriate within the Scrum framework.
Points are an estimating tool. They are only meaningful in the aggregate, and are primarily needed for estimating team capacity during Sprint Planning. Using ...
19
Story Points Estimation and Hours Estimation have different purposes.
We use Story Points during Product Backlog Refinement.
Story Points are good for high-level planning.
When we make an estimation in Story Points we talk about the productivity of the whole team. During high-level planning, only the productivity of the whole team is what matters.
Story ...
19
If you do development work in the sprint, you should estimate. If you don't, then it's better you skip on providing your own story points estimates.
You can help your team with information and advice, and support them to reach consensus, but you should let the people that do the work perform the estimates, otherwise you might be influencing them in one ...
18
According to Fred Brooks, author of "The Mythical Man-Month", the practice of adding more people to a project at the last minute may not yield the results you want. From Wikipedia, this is known as Brooks's Law:
"adding manpower to a late software project makes it later"
Software isn't like manufacturing. When I was a lumber stacker, it took me a little ...
18
Well the easy and probably not completely helpful answer is, agile requires a change in how the business plans. You fund teams, not projects.
That's not entirely helpful so let me try and bridge the gap.
The success of an agile project boils down to having a good backlog and dedicated teams.
If you don't spend time planning a backlog, then you'll never ...
18
This depends a lot on how the two companies involved in the contract negotiation operate.
You have to realize that there is always a cost of doing business, and somehow you have to recuperate it from the profits you are making. Think about your daily work, for example. You might work for 8 hours a day, but possibly you are productive and producing an actual ...
18
Hat tip to Nvoigt, Nvogel & D. Espina - all good answers, with particular emphasis on D. Espina's "sometimes, knowing one of your team is overly optimistic, you simply add your own margins to their input."
I'll just add one more frame to the question - this is a problem in risk management. The core, fundamental responsibility of the PM is to ...
15
Person-month is politically correct synonym for Man-month.
It's mean amount of work performed by the average worker in one month.
So, if:
project requires 12 persons-months of development time
all team members do only pure development activity (i.e. they are telepaths and they don't need to spend time for communication with each other). [note: this is not ...
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 ...
15
In Scrum the team aims to complete the sprint goal by the end of the sprint. It shouldn't be necessary to estimate day-to-day deadlines since the delivery date is always the end of the sprint. I suggest you could stop trying to lead, stop estimating and allow the team to self-manage.
A team of three people is quite small however, and one problem may be just ...
15
It looks like Scrum doesn't address this issue in any way?
No, it doesn't.
Scrum is a guide. Although it prescribes stuff, it doesn't prescribe a lot of stuff. This is one of the things that are left at the discretion of the implementer. For ex, it used to provide a sample for 3 questions to ask during the daily, but those were dropped eventually (probably ...
14
TL;DR
Velocity is simply a proxy for measuring team capacity over time, and shouldn't be used for historical time accounting. Always estimate based on the current level-of-effort and complexity, and this will naturally result in incomplete stories being reflected in velocity as drags on capacity.
Stories Shouldn't Carry History
Don't treat stories as ...
13
I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved.
I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...
13
Two things jump out at me.
First, the end result of a Spike is not a shippable product. Spikes are used to learn, and do research. The end result is an answer to a question or finding some information or gaining knowledge in a given area. That doesn't mean that there's not an output associated with a Spike, but it's almost certainly not a shippable product. ...
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
You can't be faulted for being confused. It is very common for organizations to try and directly match story points to a real-world measurement. This exactly defeats the purposed of using story points (and why I dislike Poker Planning for estimating).
A Story Point in simple terms is a number that tells the team how hard the story is. Hard could be related ...
12
Not surprisingly, I hear that question a lot. The basic problem with the question is that Agile disagrees with the fundamental idea of a fixed-scope/fixed-timeline project. In the question you were asked, there is the assumption that the end date of a set scope is knowable and the problem is that we are bad at knowing it (estimating). That's not really true. ...
12
The software project, already completed (and even then your historical data might be off by more than 10% depending on how you tracked it). Note: this is not a joke.
See https://en.wikipedia.org/wiki/Cone_of_Uncertainty
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
The estimate for an item should cover how long it'll take to be done. Assuming what you define as done covers testing as well as development, then it should be in the original estimate.
The best way to ensure everything that needs to be covered to reach done goes into the estimate is to ensure everyone involved (eg the testers) are invited to the sprint ...
11
First, remember that an estimate is highly unlikely to be 100% correct, so do the best you can with the information that is available to you.
Second, break down the tasks as far as you reasonably can, and get figures for similar low level tasks from other projects that have been done in the past. Don't worry if they are not identical, as long as they are ...
11
The art of giving a SWAG estimate
I have worked with many developers and development managers who are very reluctant to give an estimate with such limited information and limited time. They have been bitten too many times in the past. The main reason is even if the people asking for such an estimation understand the risks and give an assurance that it will ...
11
TL;DR
For agile projects, a basic formula for estimating budget is:
(totalStoryPoints / velocity * teamHoursPerSprint) + nonLaborCosts = budgetEstimate
The results should be reported as an estimated range using statistical confidence intervals or a "high, low, average" method.
Estimate Budget Using Iterations
The "secret" to estimating agile budgets is ...
Only top voted, non community-wiki answers of a minimum length are eligible
