Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
It seems that both these terms get thrown around a lot. Both, I think, describe the same idea. Which was established first?
Also, it seems like some people describe it as a good thing to have a low x factor, while others describe it as a good thing to have a high x factor. Which is it?
You want a high truck/bus factor:
Truck Factor (definition): "The number
of people on your team who have to be
hit with a truck before the project is
in serious trouble"
(From: http://www.agileadvice.com/archives/2005/05/truck_factor.html)
i.e. you don't want parts of the code that only one person knows how it works or only one person can extend/maintain. Knowledge should be spread amongst the whole team via things like wiki info and pair-programming.
Wikipedia says bus number is "more commonly known as truck number" But in the US, "hit by a bus" is practically an idiom, while "hit by a truck" is not (although either phrase is easily understood.) Regarding high/low being good, the wikipedia article says:
"High bus numbers are good (with the
best case being equal to the number of
developers on a project). This means
all developers understand the codebase
more or less equally. A low bus number
(especially, one) represents a high
risk."
I'd add to what #cartoonfox said: Promiscuous pair progamming is a good way to distribute critical knowledge around a team so that the truck number is as high as possible. If you don't swap pairs often and with many different team members, knowledge isn't distributed very quickly.
The Truck Number (or Truck Factor) is the number of people with key knowledge that you cannot replace i.e. if that number of people went simultaneously under a truck you wouldn't be able to carry on developing.
I believe that certain chemical companies forbid key members of staff from travelling together for this very reason...
Discussion here: http://c2.com/cgi/wiki?TruckNumber
Here's a story about Bill Atkinson being the one key person in the Mac's truck factor - one of the key people that worked on QuickDraw during the early days of the Mac. Had a car accident apparently and people were concerned that he wouldn't be able to finish his work on the Mac's graphics software:
http://folklore.org/StoryView.py?project=Macintosh&story=I_Still_Remember_Regions.txt
A high truck number is better - i.e. it's harder to wipe out that many critical people at once...
A low truck number is worse - i.e. there is a greater risk that a few critical people could be ill, or leave or die, leaving the project in a state of unrecoverable collapse.
Pair progamming is a good way to distribute critical knowledge around a team so that the truck number is as high as possible.
The principal is the same, whether you call it:
bus number
truck number
bus factor
truck factor
et al
Also, the principal is the same whether or not you describe it using a higher number as being better, or a lower number being better:
A high bus number is good if you are describing the number of project members who could be hit by a bus and have the project survive;
A low bus number is good if you are describing the number of project members who survive a bus crash and have the project survive.
I did look into it once upon a time, but I don't recall which came first (see #Paolo's answer). Regardless of which came first, I have experienced enough confusion about it that I make sure all parties are using the same version of the number, high or low. ;)
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Why so? I really can't understand that. Why we can only select from numbers proposed by players?
The numbers used are spaced far apart on purpose (typically from the Fibonacci sequence). If you get numbers from all across the board from 1 to 23, you're supposed to ask why the person who voted 1 gave it such a low score ("Did you think about testing and deployment? What about these other acceptance criteria?") and why the person who voted 23 gave it such a high score ("Are you aware we already have an existing code base? Did you know that Karen knows a lot about this and can pair up with you?") and then re-vote. If you're really stuck because half the team says 8 and the other half says 13, you can take the 13 and move on with your lives.
The extra precision isn't necessary when your accuracy is not great. My team goes for even less precision and buckets stories into "small" (one person can do a bunch in an iteration), "medium" (one person can handle a few of these), "large" (one person a week or more), and "extra large" (too big and needs to be split).
You can do what you want to do. However, the thought about choosing the exact numbers that are proposed is that with growing numbers, you cannot estimate small details reliably. That's why with growing numbers, the gaps between numbers become larger.
Once you start giving detailed numbers (like one estimating 8 and the next 13, chosing 11 as a mean) people assume this actually is a detailed estimation. It's not. The method is meant to be a rough guess.
Behind the idea that people should agree on one number is that everybody should have the same understand of the story.
If people pick very different numbers they have a different understanding how much work needed to complete the story or how difficult it will be. The different numbers should start discussions then and finally lead to a shared view of the story.
You should think to numbers as symbols with none arithmetic meaning, except for a (partially) ordered relation, because they are estimates (of effort need to do done a user story).
If you use math to model an estimate you should provide a way:
to represent certainty
to represent uncertainty
to operate with that representations
to define an average as a function of certainty and uncertainty
If you use some kind of average which operates on estimates modeled as single numbers you are supposing that certainty and uncertainty can be handle in the same way, and I guess it's a bad assumption.
I think that the spirit of planning poker session is achiving a team-shared estimates by a discussion among human being and not using arithmetic on human being estimates.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Im the context of pair-programming ...how do you estimate? A 5 point story ...split in to 3 tasks...each task being swarmed by 2 members. Does it mean it mean it is finishable in half the time?
You estimate using points. The number of points achievable by a pair is called velocity. Check this: http://en.wikipedia.org/Planning_poker
I always stress story sizing over estimating. If you can minimize the variation in size between stories, then estimates become much less interesting. That is, estimation activities lose their value when the difference in size between any two stories is small, which helps fast teams recoup the cost of estimation and put it toward something productive (like building product).
With that in mind, I would suggest proactively pruning the backlog and splitting five point stories into smaller ones (still thin vertical slices) whenever possible. Until your team is experienced, I'd suggest you continue to have estimation parties, but prompt a default estimate of 1 point to each card, with a quick consensus check or discussion as to why any justify a bump to a 2 or 3. For anything that's clearly bigger than a 3, I'd suggest challenging that one of two problems is present: the baseline value of "1" is too small or the story should be split (either made more specific or tracked as an epic).
As the team establishes a decent velocity, the activity can hopefully shift its mindset from estimation to mere story vetting. That is, the question during planning of "how big is this story?" becomes "is this story abnormal?" The latter question takes significantly less time to answer.
Most Agile methodologies suggest that you should estimate in points. However, there are many successful teams out there - including several advanced and highly productive Kanban teams - who estimate in hours. Points come with their own games, perverse incentives and problems. YMMV. Anyway...
I've heard figures of 25% more dev-hours for a pair completing a task. So, the task would be finished in 62.5% of the time, using two developers instead of one. However, the quality of and knowledge-sharing often increases too. Since bugs = rework and rework takes longer than doing it the right way the first time, pair-programming usually pays for itself. This differs for different tasks and levels of skill, eg: simple bug fixes, novice programmers, etc.
In my experience 2/3 of the time is a pretty good ballpark figure. It's longer than 1/2 but less than it would be with just 1 person.
Sallyann Freudenberg is a good name to look up regarding pair programming research. You could also check out the refs on the Wikipedia page:
http://en.wikipedia.org/wiki/Pair_programming
The figure is mostly borne out by the data in this report by Alistair Cockburn and Laurie Williams: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
Pair estimates how long it is going to take them. Any estimate is based on experience - the longer experience team has with the project, with technology and with working together in pairs the better the estimates will be. Any arbitrary percentages like add 25% for pairs etc. are of any use only at the very beginning - with new project and new team on new technology - where you have nothing else to base estimation on yet. As soon as experience starts building the estimates will improve.
Remember though, that they are just this - estimates, that is our best guess of the future derived with the help of experience and knowledge from our understanding of the present. It's like weather forecast - the more data we have, the more experience forecasters have the better it is, but it is just a prediction, not reality.
Which is why points are so great, because they help you estimate one parameter you can - how "big" the tasks at hand are.
1) A simple, concrete way to think about estimating units is the number of check-ins it would take to complete the story.
If you're doing TDD, continuous integration and refactoring you'll be working in small, chunks of work, keeping the build green and checking in regularly so under those conditions single check-ins can be a meaningful unit of estimation.
2) Alternatively, think about blocks of uninterrupted pairing time in a day e.g. after stand-up to coffee break, after coffee break to lunch, after lunch to mid-afternoon break, mid-afternoon to going home time - say 4 periods a day.... so say 4 units is a single day. That gives you a bound on what you could expect to do in an interation...
Personally I go for the number of check-ins, because I can sketch out roughly the tasks involved and get an idea of check-in numbers.
The great thing about number of check-ins is that it doesn't matter if you're pairing or not - you're just tracking what you can get done.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Summary
We are start up and we provide software development services. We develop windows, web, services and mobile applications. We were aware of agile and we are scrum certified developers . We do user story based estimation and task planning. No issues.
Issue
We are approached by many small customers. Customers says very high level features or few words about the concept of their dream project. They asks for Effort Estimation and Cost Estimation. Mostly they are interested in Cost.
For each customer we did create the user stories and estimated the user stories and based on story points, we estimated the effort in days and we convert the days to the cost based on hourly rate. We involve the team of 3 or 4 people and get the estimation done. We spend at least 20 to 30 hours of team total time for estimation. (Team of 4 discussing for 5-6 hours)
The problem is that many customers would never turn back. We do not want to spend 20-30 hours of team effort. We don't want to use the exact user story estimation that we follow for contract signed project.
Question
What could be done in order to provide approximate estimate for small customers with small business?
I don't know there is a solution, other than to find 'better' customers. It sounds like you're doing it right to me. Non-technical customers often want you to spend 30min on the phone with them and then give them a price for the whole thing, so it's good you take the time over it properly. However then you often waste your time.
Maybe you need to say 'no' to customers who you don't think are serious. Or charge for the time spent doing highly skilled estimation work.
By 'better' customers I mean bigger companies, who are more experienced with software (and also probably have bigger budgets). The downside is more paperwork - you are much more 'free' dealing with small firms but also more at risk.
You don't have to stick to a fixed-price contract, for requirements that are vague you should look at doing time and materials.
Basically you need to spread the risk of the cost of overrun between you and the client.
A hybrid option might be to do some T&M proof of concept work then fixed price for the rest when you understand it better.
Alternatively, if you client has a pot of money then use your agile strengths to work with the customer to incrementally deliver functionality until they run out of money.
"We do not want to spend 20-30 hours of team effort."
Then don't.
If your estimating method is too costly, stop doing it.
"Customers ... are interested in Cost."
Then get them a cost more quickly. Do less work. Don't use a team of 3-4 for 20-30 hours. Have one person do it quickly.
One person can create a spreadsheet with stories, story points, priority, hours and cost. That's the project backlog for Scrum. That's the estimate. That's enough to start a conversation. It's not a fixed-price estimate.
A simple spreadsheet with stories, story points, price and priority is all you need. Then you can work with the customer to adjust priorities to determine how many of those stories they can actually afford to buy.
If they want a fixed price, you simply need to review each story summary to see if the points are right. You already have the spreadsheet, and the priorities, and the formula to compute price.
The unfortunate short answer is you are going to have to significantly reduce your estimation costs. The only way to do that is to reduce the number of people to one and use a formula approach.
Take a best guess. Put reasonable assumptions in the contract. If you do a decent job, some will be a little high, some will be a little low and it will average out in the end. If you are off by too much, track changes within the project and charge for them. The key will be in the assumptions placed in the contract, usually in the form of a statement of work.
This is normal business, from small projects to enterprise projects. Just a matter of scale. It doesn't have to be done this way, but it often is.
This reminds me of the challenge between time, money, people and overall quality. Some people can see this easily and others may struggle with the idea. Part of the key point here is to understand is what kind of expectations do you want to set and what kind of leeway do you have with the customer. For example, how are bugs in the software or overall support factored into the project.
You may want to consider how much work do you want to do upfront and on what kind of scale are you spending the 20-30 hours estimating a project. Comparing the cost of that much time spent generating an estimate, which # $40/hour is $800-1,200 by the way, to what the revenue from the project would be is something to consider. If the entire project is $400, then was it worth spending twice that coming up with an estimate? On the flip side, for million dollar projects, it may well make sense to spend that kind of money.
My suggestion would be to see if there is a cookie-cutter approach that could be taken for their projects so that there isn't as much variability to the projects if that is possible.
Theres two sides of estimation, first creating the initial 'ball park' figure this should be done relatively quickly, it should be emphasised its a ball park figure and its the start of your conversation with your customer, its not a contract. Second you do your more detailed team based estimation.
This is how this consulting company does it - Ball Park Estimating
Create a template spreadsheet with times and costs for typical pieces of work, look at the initial requirement and update your template. Start the conversation with this is the ball park but we will need to work together to confirm a final price and get a more accurate estimate. This more accurate estimation process will take x hours and cost x dollars.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When working on fixed price software development projects, I frequently find myself having to estimate the total number of hours a project will take after the price is set, but before the work is started (or VERY early on in the development). Unfortunately, these types of projects are best developed using an iterative/agile method, which means that we don’t (and really can’t) do a complete up-front design.
In a typical scenario, we would have a contract that has X features and Y dollars. After contracting, the engineering department would then need to estimate the number of hours required to complete the X features. There are several possible reasons to need this information up front, including:
• The Y dollars translates to Z hours available, so we have to make sure that time(X)<=Z, perhaps by reducing the scope of X.
• The delivery date is set, and so we have to assign the appropriate resources to meet that date.
Kelly Waters has an interesting take on estimating agile here: http://www.agile-software-development.com/2009/04/agile-estimating.html Unfortunately, these are estimations of difficulty, using a points system, and do not translate to hours.
It seems to me that we need to be able to do one of two things:
• Obtain contracts that have a huge amount of flexibility in them to accommodate an agile development process.
• Figure out how to provide reasonably accurate up-front estimates for features that have not yet been designed.
The first option is of course not an option in most cases.
Does anyone have any advice/guidance on how to generate up-front estimates in an agile development scenario?
Alternatively, does anyone see another option for solving our problem through some other process change?
I think every client wants to have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.
So, there are at least two documented ways you can do this and both are described in the "Agile Estimating and Planning" book by Mike Cohn that i strongly advise everyone to read.
Before your project even starts do the exercise of breaking down your stories in tasks and estimate each home in hours. Do the budget math with those estimates. Keep in mind that these estimates will only be used to reach the estimate time/budget. When the project starts the team should be responsible for estimating and creating the tasks like normal.
Use historical data. If the same team has worked before on a project with similar technology then you can use the past team velocity to estimate the project cost.
Again, for more details on how to do this read the referenced book.
Big Upfront Estimation is just Big Upfront Design with $$$ attached
You don't, that would go completely against the entire paradigm of agile.
Agile can be about Fixed Costs
What you can do is set a date and then work torwards it in iterations/sprints and let the product owner(s) decided what is important to get done by that date. In this way a Sprint of 1 or 2 weeks is a Fixed Cost the same way it would be in an Big Up Front Design would be, it is just a smaller fixed cost.
The entire premise behind agile methodologies is to do away with arbitrary deadlines and the death march that they become because change is not accounted for in the contracts and deadlines. SCRUM works, is a great starting point to build a methodology on, read about it and do what it says at least as a starting point.
Short Sprints with customer feedback and approvals
Give you a starting point to refine your future estimations upon, and helps you gain trust from the product owner and customer very quickly, because they see their most important concerns delivered in a very short amount of time.
Fixed price in Agile gives you a number of iterations you can run for a given team size. The point of Agile is then to maximize the value you can get during these iterations. Agile is about scope management.
So, you actually shouldn't do upfront estimations. This would mean fixed scope which is the just the opposite of Agile or anti-Agile if you prefer.
Agile doesn't work like this, you need a new kind of contract, as pointed out in another answer. See for example 10 Agile Contracts and/or google.
Instead of aiming for a contract for the "entire" project, you should create a contract that just runs for a month or two.
Set some very low goals, perhaps only two or three features.
Explain to the client this is a discovery phase of the project. Without this phase you cannot give them an estimate for the entire scope. It would be in no ones interest to give them an inaccurate estimate.
The client benefits in the following ways:
Lower upfront cost (only a fraction of the total price). If things go tits up there is a limit on their financial exposure (sensible given that most software projects fail).
Have working software within a couple of months that may immediately solve some of their problems
Have working software to provoke thought/conversation about requirements
Client will discover more about what they actually want
Client gets to see how well you work. If they don't like it they can look elsewhere.
"you don't, that would go completely against the entire paradigm of agile": I think this is quite incorrect. Agile is common sense based and nobody would invest in project if they had no idea how much it would roughly cost: they understand they may have to cut scope to meet deadlines or increase budget and/or extend deadlines to deliver the whole scope. On my company projects, we estimate projects by comparing their size and are also estimating epics using poker planning. Using the cone of uncertainty, and without trading off quality, we are about maximum 50% off on our estimates prior to starting the first sprint compared to the reality. And we will improve as we build up our Agile expertise (on accuracy and time to get first estimates).
You can't expect marketing to sponsor projects for 3 sprints (so up to 3 months) to have an idea of how much it would cost.
If you estimate the backlog items in story points (which is discussed in the Kelly Waters article you link to) then the question becomes how many story points do you expect your team to deliver in a sprint. If your team has been working together before, then you should be able to take a guess at this (perhaps with upper and lower bounds to indicate a confidence range).
If the team haven't worked together before, then you can take a few well-understood stories and break them down into detailed tasks. This will give you a man-hours number and you can compare this against your story point estimates to try and predict your velocity. Again, a confidence range of upper and lower values is probably appropriate.
Let's suppose your user stories add up to 150 points, and you predict that your team can deliver 15-20 story points per month, then the work will take 7.5 - 10 months (through simple division).
The advantage of this approach is that you can measure the team's actual velocity, and compare it to the plan. Re-estimating you timelines should also be pretty easy, e.g. if you discover after a couple of sprints that the team's velocity is actually only 10 story points per month, then you can easily predict what your revised timelines will be.
Do bear in mind that team velocity does fluctuate for a number of reasons. It is typically lower at the start of a project when the team is still forming. Also the team is most likely concentrating on infrastructure concerns at this point rather than delivering functionality.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
with agile estimating, is it true some say to choose intervals like 1/2 to 1.5 days only?
It tends to be a good rule of thumb (agile or not) that your tasks should be broken down into at most 1 - 2 day increments.
The idea is that if you have larger chunks than that then you haven't broken the task down enough and you will more likely miss the estimate and miss it by larger amounts of time than had you broke it down. Often when you break it down you discover your initial estimate was off and since you have broken the task down into more concrete tasks your estimate is now more accurate, more trackable and meaningful.
For tasks that are coming up on your to do list soon you should pay attention to this but for long range planning where you haven't necessarily thought out the feature in detail I think larger estimates / tasks not broken out for the feature is OK.
Here's a link to Joel Spolsky talking about this. Take a look at item #5 about half way down the page.
http://www.joelonsoftware.com/articles/fog0000000245.html
In my experience, any estimate that's longer than 2 days is probably hiding serious work that should be broken down further. Such estimates have a very high probability of going over. Try to break everything down into smaller chunks so that no individual chunk costs more than 1-2 days.
There are advantages to keeping the estimates short. It forces you to break up large tasks into small, discrete tasks that can be measured and discussed quickly, which helps promote the entire Agile development process.
That being said, I almost never keep a "rule" as a hard and fast rule with things like this. I'd say this is a good guideline, however.
My team consists of junior programmers (university students) and we've found that it's generally easier if we break all the large tasks down into a bunch of smaller ones. It involves more forward-thinking but in the end we are more productive and can it's easier to evaluate our progress. It also brings a sense of achievement when you have something completed at the end of the day.
I would agree with that guideline. Anytime I have ever taken on a 5 day task, it has degenerated to a three week nightmare. Large estimates indicate you didn't learn enough about the problem up front to know what is involved, because if you had, you could have found ways to break it up better.
I don't agree. If a team's iterations are two week long, the 10 days mean that 1 day would be spent for iteration close (show & tell), iteration planning and tasking or planning poker.
When playing planning poker, a team either geometric or Fibonacci progressions for estimates. For example, cards would contain values such as 1, 2, 4, 8, 16 or 1, 2, 3, 5, 8, 13. Each number reflects the number of days of development for a pair of programmers.
For each card, once discussion has occurred, each member simultaneously plays the card that reflects their estimate. If the majority of the team converges on the same estimate, the estimate is accepted. If there is much variation in the estimates, further discussion occurs (members explain the reason for their estimates) and another round of voting takes place. This occurs until consensus is reached.
If a number greater than 8 is picked, then the card is deemed to be too big and the card is refactored into at least 2 smaller cards. The reason being is that such a large estimate indicates the card is too big to be completed in a single iteration and any estimate is very likely to be inaccurate.
Using such a method brings commitment from the team members to delivery all they have committed to and for a new team the estimate become so accurate that carry over of cards soon become a low risk.
A very good post about agile estimation and planning you can find on the blog of agile42: Just enough, just in time
A lot of good answers here, so I'll play devil's advocate and approach it from a different side.
There's a possible problem with breaking down things into very small estimates (# of hours) when doing things such as release planning. David Anderson discusses it in his (excellent) book Agile Management for Software Engineering.
Basically, the idea is that with a task that is very small, a developer will pad his estimate by a fair bit (say, turning a half hour into an hour, or doubling it) because of a certain amount of ego that would be bruised if the developer failed to complete such a small task in the estimated time. These local buffers add up quite a bit and result in a global buffer that's far bigger than it needs to be.
This is less of a problem if you stick with .5 days as a min - it's basically assumed that there's some buffer in there, so you won't need to pad it any more.
I feel there is a bit of mix of information and overlapping in this thread... allow me to make my point :-)
1) The Fibonacci sequence, that is very much use through the Planning Poker technique from Mike Cohn, is about estimating "Complexity" of User Stories, which are - as Cam said - normally written on cards, and entail more than one task, at least all of those which will be needed to make a Story shippable (Ken Schwaber, Alistar Cockburn, Mike Cohn...)
2) The tasks that are included to complete a Story, are normally estimated in Ideal Hours or Pomodori (Francesco Cirillo, "The Pomodoro technique"). If you estimate in Ideal Hours normally the rule of thumb is to keep them between 1/2 day (3 ideal hours) and 2 days (12 ideal hours) of work. The reason for this is that doing so the team will have more qualitative status information by having at least every two days a team member reporting a Task as done, which is much more "valuable" than a 60% done. If you use Pomodori they are implicitly "timeboxed" to 25 min. each
The reason to keep tasks small comes basically from the "Empirical Process Control Theory" for which through transparency and regular inspection & adaption, you can better check the progress of your work, by quantifying it. The goal of having smaller tasks is to be able to clearly describe and envision in details what will be actually done, without adding too much of "guessing" given to the natural uncertainty deriving from having to predict "the future". Moreover defining an outcome and a shorter timebox allow people to keep the focus with enough "sense of urgency" to make it a challenging and motivating experience.
I would also catch up the point of the "motivation" and "ego" - from Chris - by adding that a good way to have people committed and motivated is to define the expected outcome of a task, so to be able to measure the results upon completion, and celebrate the success. This idea is encapsulated in the Pomodoro Technique, but can be achieved also using ideal hours for estimation. Another interesting part of the Pomodoro Technique is that "breaks" are considered "First Class Citizens" and planned regularly, which is very important especially in creative and brain intensive activities :-)
What do you think?
Best
ANdreaT