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

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

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


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


11

My company will sometimes engage into a "discovery" phase where we will spend 20-80 hours detailing the exact requirements of the project and determining the cost. We do this if we believe the requirements are not well documented enough or the project is so large that being off on the quote plus or minus 10% could mean 10,000+ dollars. The rate at ...


11

I know there is an accepted answer, but I find it to have a bit of a trap in it, so I want to provide this answer for another view. I've been practicing Scrum for about 15 years and I have yet to encounter a task that could not be usefully broken down to less than a sprint. This has been in industries ranging from construction to marketing to research on ...


9

Estimates are a tool that supports planning. Anyone that needs to make decisions and build plans about the future can use estimates as a tool to make predictions and figure stuff out (without knowing for sure, you can only estimate; but having an estimate - any estimate - is sometimes better than not knowing at all). So for example: upper management can use ...


8

Pre-sales work is normally assumed to be at the vendor's expense, but usually I would expect the activities you describe (analysis and design) to be part of the work the customer pays for after the contract is signed rather than before. Detailed analysis and design requires extensive commitment and work from the customer as well as the vendor. The price you ...


8

The Scrum Guide says that the Development Team are responsible for all estimates. Where the SM isn't also a member of the dev team then it should be up to the team to what extent the SM participates. It's reasonable to contribute to estimation discussions if you have something useful to say but I would suggest you take a back seat so that the team feel that &...


8

Notwithstanding your approach and whether you are performing it properly, research the affects of planning fallacies. A planning fallacy is a specific form of Optimism Bias, where we have a tendency of under estimating adverse variables that could impact our performance and, therefore, we predict far favorable results than what is most likely. The bias ...


6

The three main reasons why a late project ends up later if more people are added to it are - as pointed out in the Wikipedia page: The new people need to learn, so they take time away from the existing people in the team for help. So less resources to do the work while the new people become productive and actually start contributing something. ...


6

Joel Spolsky once wrote: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right. ... A typical bad estimator has velocities all over the map.... Most estimators get the scale wrong but the relative estimates right. Everything takes ...


6

First of all backlog items should not generally be "tasks" at all. Wherever possible backlog items should be deliverables, features or other outcomes. Do you have an example of a backlog item that cannot be split? Most big deliverables can be split. Consider a typical sprint consisting of 10 working days (2 weeks is probably the most common sprint ...


6

Because Kanban is not a full framework for developing products in itself (it's a method to optimize another process), there are many things it doesn't specifically account for. However, teams often track throughput in either item count or even story points if they chose to use them. You can forecast release timelines with either item count or story points ...


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


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

I'd like add one more option on the table. In many cases estimation isn't really necessary. Situations when it can be useful: You need to sync with other teams which depend on you You need to predict the budget and decide if the project (or a feature) is worth starting In any case, if you estimate there has to be some decision made based on the estimates. ...


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


4

This seems like some kind of theoretical question, but I can give a few pointers on how to approach this. You've already identified: Velocity (the number of points that can be done in a sprint) Backlog size (the total number of points left in the backlog) The simple formula for "how long until we're done?" is Backlog Size / Velocity. This gives ...


4

People tend to focus on improving estimates, when in fact you should be focusing on delivering value as quickly as possible. If, as you say, 40% of a given cycle is issues and the other 60% are stories that are in flight over multiple cycles, then it seems the team isn't delivering. Getting better at estimates or changing how you estimate by introducing ...


4

Individuals don't have velocity, teams have velocity. Even if you have two roles in the team (backend and frontend), with some people unable to do other people's work, it's still the team as a whole that delivers work. Can you deliver only the backend to the user, with no frontend? Or the other way? No. So the sum of all the story points delivered in a ...


4

Using the team's velocity as a guideline does not seem right because then the backend developers might end up with more work than the frontend developers or the other way around. What a lot of teams will do in this situation is to estimate in story points as a team, but then sanity check that they aren't overloading one particular specialism in the team. ...


4

Since you mention sprint planning I will assume your team are using fixed-length iterations. Estimates are for the team. The team should include the senior stakeholder or the person who is accountable to stakeholders of course (e.g. the Product Owner), but the main purpose of estimation is to allow the team to decide what can go into a given sprint. The ...


3

These costs are (usually) covered by the vendor. This is inherent risk, which can bankrupt small, specialized startup, especially if it enters the market under-capitalized. As a side note, this was for example a reason my university lab stopped working directly with clients seeking customized solutions. We only work with solution-providers who do this task ...


3

Affinity estimation is a fast estimation technique usually used for release planning. You have a product backlog full of items (or a list of the most important items) and you want to get an airplane view of how many sprints the team will need to build them all. Knowing the team's velocity and sprint length, the goal is to estimate the total number of story ...


3

Sadly, I fear, like Bogdan implied in a comment, that the answer is largely going to be 'no'. That being said, there are some things you can do. One of the biggest would be measurement. After you finish a project, start inspecting and recording its actual financial impact. Measuring the past is always going to be much more precise than estimating the future, ...


3

Further complicating the real-life situation is that there can be complex dependencies among the identified tasks, reflecting the architecture of the underlying system. Scrum is, and can only be, a guide. Take it for the many very-good ideas that it contains, but don't worship it.


3

Just another perspective... In the organization where I am currently employed no one "consumes" the estimates, and everyone knows that. Yet, we are still pointing stories/tasks. The goal of the exercise, for this organization, is not the points, rather it is the discussion to create a shared understanding about the work items, and it is the ...


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