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


14

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


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

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


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


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

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


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

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


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


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

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

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

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

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

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


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

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


2

You can't calculate EV on the 10 items yet because they aren't done, so you don't know what the total effort to complete them is. You could calculate EV on the 5 that were completed if you had estimates for those 5 independent of the other 5.


2

I’ve finally reached out to the person who conducted the estimation meeting in the company where we used that method and he told me to search for “magic estimation”. We used a variation of it. If you search for the method online and read the description, you will find a slight difference: All team members estimate in parallel, though each team member gives ...


2

Alright, please don't shoot me but I'll argue against what most people recommend here, and that is to split certain test activities into their own stories. Just to be clear, with test activities I am specifically referring to authoring automated test cases. Manual/exploratory testing is a bonus. Let's start with some theory for which I'll use my go-to ...


2

I am in similar situation with a team of DEV & TEST people. After several Sprints, we have agreed to have a norm for "Normal stories" that Dev/ Test effort ratio is ~ 2:1 (= current team structure with 6 DEV & 3 Test) We are not really converting Story Points to hours but we built a common sense to forecast Dev & Test effort based on ...


2

Reliability and validity of estimates depend on what you define as an estimate. I am answering this question not from a Scrum perspective but rather generally regarding estimation. I unequivocally disagree with any "no estimate" point of view. The reliability and validity of an estimate will never be 100% perfect because it is a prediction of the future ...


2

I see three options. My preferred option, in this case, is to have stories A and B. The work for C would be denoted as something that needs to be done in both of them. If the team is estimating, then I would estimate both as if the other didn't exist, and the set of work C was part of both. This enables you to choose which one you do first without missing ...


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