Quote Series Part 2 - Estimates and DONE

This is part two of the series, to see what this series is about, review part 1.

Quotes on "DONE"

One of the goals of the sprint is to measure what you have done - ObjectMentor coach

Burn-up should happen every day to stop scrunch stress (all things shouldn't finish on the last day) - ObjectMentor coach

If we’re not shipping our software when it’s ready, it’s poor business practice. If we’re not sure whether our software is ready, it’s poor software practice. - Ron Jeffries

Make Ship Happen - Todd Little

Quotes on "Estimates"

Ability to estimate correctly is not an ‘ability’ … it is a fluke and lucky guess - Roy Morien

Estimates only help us take action to get to the next step - unknown

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Are Deadlines Important?

Olga Kouzina posted about deadlines on her blog here. She then posted a related discussion thread on LinkedIn's Agile and Agile Alliance groups. Next thing you know, there are 26 combined comments between the two threads!

She is basically questioning the core concept of deadlines. Do we need them? What value to they add? What negative impact do they carry? Unfortunately, some people mistakenly took this to mean that we should never work with goals, delivery dates, or time based measurements. I had to clarify my stance later in the thread with the following:

I believe in and agree with groups that leverage timeboxes, iterations, and release dates. I see these as good metrics and motivating goals.

I believe that Olga and I were talking about Deadlines with a capital "D". These are the dates put in the ground before the team has committed to scope, effort, etc. We know the requirements will change as we work the project, why won't the date change also?

I've seen too many projects where you realize pretty quickly that the "Deadline" was picked due to a desire but no real business need or planning validation. These dates are a great way to de-motivate a team... after all, why work hard if you already know you can't make it?

When Olga asked why I might think we put up with deadlines, I responded with:

We stick to them because people with higher authority don't trust a better solution and force them on us.

So... it's our job to start educating the decision makers around or above us. This is a topic I recently blogged about.

Ben Linders summarized the agile point of view well with the following:

If there really has to be a deadline, then it's up to the PO, project managers and stakeholders to do whatever they can to ensure that the teams know what to deliver, and have an enviroment and the right conditions in which they can be most effective and efficient. IMHO the deadline should never be passed on to the teams! The teams commits to iterative deliveries of highest priority user stories. That automatically leads to maximum result in the shortest time, which increases the change that deadlines are met.

And finally, I like Vinay Krishna's points:

Can we achieve anything without deadline? It looks funny to know that one starts a project and says that he doesn’t know when it would get finished.

I want to quote here the famous Parkinson Law which states that “Work expands to fill (and often exceed) the time allowed.”

This is important to recognize in software development because when we are not restricted by time and/or money, it’s easy to create an endless amount of features or strive for what we perceive as perfection.

Of course we can all agree there are sometimes market reasons for deadlines. After all some dates can't be moved (Y2K, elections, tax dates, etc).

Testing, Estimates and Burndown...

Adam Feldman posted the following question to the Agile Alliance forum on LinkedIn:

In your experience, what do you all do in estimating for testing? Do you include the time expected to test the story in the points allocated for the actual story, or is this normally not included?

The second part of my question regards burn down charts. If we are not allocating points to the actual testing of the story, is the burn down chart really only telling us what is built - not what is actually complete?

The first three responses answered that testing should be part of the team effort and not an after-thought. To help Adam find a way to explain this for the team and management, I focused on the concept of DONE criteria:

The fundamental question here is "what is your DONE criteria?".

If the team's DONE criteria is built (but not tested), then the burndown and estimates do not include testing. This will lead to an optimized development team, but potentially create problems for testing and ultimate delivery. Things will get built faster, but ultimately may be delivered slower (which is not upper management's goal).

If the team's DONE criteria is delivered business value to the user/customer (the true agile definition), then the estimate and burndown includes testing effort. Testers should be part of the team, tests need to be run within the sprint, stories should be completed within the sprint including testing.

This isn't easy, but the second option is the mature one.

There are two pieces to overcoming this. You (the testing group), need to learn to work quicker and more closely with the people building. They (the developers) need to learn that DONE is defined by business value and not code complete. If "you" and "they" both overcome this, then everyone will become a "we" or "us". Testers become involved in sprint planning and review also.

I've blogged about this several times if you are curious:
Downstream testing
Tests after story closure
What to do with found bugs
How do testers fit in agile

I'm curious where the discussion thread will go over the next few days on LinkedIn. Anyone have additional thoughts?

Good Enough Metrics...

Another post triggered by my interaction with other customers using VersionOne. We were discussing story points, velocity, capacity, and other metrics. Here's what Tom said when he was trying to figure out team capacity each sprint:

As an example some of our teams state the base capacity of every team member (assuming a 2 week sprint) is 10 days * 6 hours a day. The 6 hours rather than 8 is to account for emails, minor interrupts like unplanned meetings etc. Then they reduce capacity based on company mandated holidays (we are global so ever office is different), then they reduce hours for the sprint meetings. this becomes the max anyone on a team can contribute to a sprint. The team members may additionally subtract off vacation time, or other meetings they are required to attend, trainings, etc. it would be nice if a team can define a default formula based on known factors, and team memebrs have an additional ability to have thier own formula that can further adjust thier own availabilites beyond that, or even just override it with a typed in value.

Wow! This sounds like a lot of work! Does this additional planning accuracy actually provide a similar level of accuracy predicting the outcome? I'm guessing it doesn't. When we transition to agile, over time we slowly learn to trust what our agile coaches / education told us up front. Here was my response:

This is great and I remember going through this myself. I had excel spreadsheets in the back of my sprint backlog where I could enter holiday and other data to get this value.

What we found over time was that it became somewhat unnecessary as your velocity and team matures. We slowly transitioned to story points and relying on them to do sprint planning. We picked our stories and blew out the tasks for them only when the story was picked up (mid-sprint we swarmed on open stories and closed them every day instead of running them all in parallel). We did just in time task planning and estimation (more efficient).

This led to us no longer needing all those calculations. Holidays and vacations were a simple head calculation (example: typically we do 20pts per 10 day sprint with 10 people = ~.2pts/person/day, we have 5 people taking 1 day of vacation = ~1pt... so plan 19 pts this sprint.)

It's an interesting problem to solve in the short term, but I'm guessing every team will have a slightly unique view on the calculation... and I'm guessing most people will outgrow this need over 6 months to 1 year.

I'm a strong believer that conversations of planning and capacity should focus on days and story points, not hours and tasks. Without getting into the debate that estimation isn't needed at all (that's another discussion), what are your thoughts?

Estimation in Kanban?

Before I start, I should note that there is a lot going on in the Agile community related to Lean and Kanban. In case you've been in a cave, you might want to check out this great slide deck by Henrik Kniberg comparing and contrasting Kanban vs. Scrum, or check out Karl Scotland's blog on the topic.

That being said, Anna Forss blogged today about how estimates do or don't fit into Kanban. An excerpt:

The main reason for estimating tasks is to be able to decide on an appropriate work load during the sprint. During the sprint planning meeting, the team estimate how big tasks are and when the work load (estimated task sizes) matches the available resources, the team commits to the sprint backlog.

So, how about kanban?

Jump to her full post to see how she answers this question.

Here's my comment on the topic, even if it is a little open-ended:

I was under the impression that estimates aren’t needed as much in Kanban because items are supposed to be closer to being “of similar size”? Looking back to the original Toyota manufacturing process application, this would have been true.

Otherwise, a large item might hang in your work queue for weeks (because it is too large) while small items fly through. If several large items “get stuck” then it might clog the whole kanban system.

So… do you need to estimate to insure that items are small and closely equivalent? (maybe)

This also make the concept of MMF (minimal marketable feature) an important goal when writing stories!

Help! Our estimate was off by a lot!

Another LinkedIn discussion, this time the question was along the lines of estimates that turn out to be incorrect. In this case, the person asks what the team should do when something estimated at 6 hrs turns out to actually take 26 hrs.

Wrongly estimated stories normally create more pressure on team which in turn impacts the quality, velocity and off course targets.

Is there any way to handle this issue? It is ok to pop out some stories in between sprint?

Most of the initial responses focused on the fact that estimates are always slightly wrong and that this error will normalize itself out. One person before me suggested mid-sprint correction with reflection during the retrospective. I agree that trends of estimate problems should be reviewed, but the real question was... what do I do right now in the middle of this sprint?! My response:

If you uncover something mid-sprint where your estimate will be 4x greater than originally thought, I would assume you have uncovered an impediment or complexity that was unknown during planning. This will happen from time to time, even on a mature team (otherwise you might not be doing difficult enough work!).

My advice would be to pull the product owner/customer in immediately. They need to understand the issue (and hopefully the cause). They need to decide if that story is still important to them at that cost. They may want to descope it knowing that everything else in the iteration is more important than that one thing. Or... they may tweak the requirement to get the majority of it and work around the problem.

I follow most scrum ideals, but I don't believe that a sprint's scope cannot be changed mid-iteration. (Actually, I'm doing a Kanban/Scrum blend now). It makes sense to re-evaluate when these things happen because the team has to remember that the largest goal is delivering the right business value. Delaying multiple expected items for a single item is a decision that should be left to the product owner/customer.

I'm curious to see what others add to the discussion thread. Unfortunately, I think most people are focusing on pure Scrum (ignoring other Agile flavors) and are assuming this is an immature team. I don't know if that is the case for this person or not.

When is a story too large?

Peter Steven's posted on the Agile Software Development blog today on the topic of "When is the story too big?" It's a really good article if you are on a team having trouble with that single story that deep-sixes the entire iteration.

Some of his points are:

• Past Performance is a good guide to future performance
• Stories should be small compared to the size of the sprint
• ‘How to demo’ makes the complexity clear
• Splitting Stories which are too big

On the second point he states:

My own rule of thumb is that no story should consume more than 40% of the teams estimated capacity. Why? An estimate is merely an estimate. If your team is knowledgeable in the technology and domain, each story has a nominal tolerance of +/- 50%. So 4 days could be 6 days, and you would still be in your tolerances. A six could be a nine. Assuming your capacity is 10, then committing to a 4 leaves a lot of room for error. Committing to a six exhausts your margin for error, especially if you commit to other stories. And anything bigger has a high risk of not getting completed, even if things go well.

I actually took this a step further in my comments:

I would decrease your 40% further.... I am a strong believer in MMF (minimal marketable feature) and encourage items that can be broken down smaller to be. If something can be built and marked DONE in a day, that is better. Remember, sizing allows for change in scope and priority mid-iteration if needed. Large stories block this.

Thus, my rule is around the 25% mark. If a story will consume more than a 1/4 of the resources in a sprint AND it can't be broken down further, then I call for a spike. Use the spike to R&D the riskiest parts of the story and flush out the demo/acceptance criteria. Timeboxing the spike to 10% of the sprint forces re-evaluation before creating a huge time sink (allowing time to refocus 2nd spike in the same iteration if necessary).

The outcome of this timeboxed "spike" should be a more clearly defined, lower risk, and possibly broken down set of stories. Containing the work to a timeboxed spike insures the team continues to deliver other stories in the meantime.

Also... these stories should be tackled early on in the release cycle. If you wait until the 2nd to last sprint in the release cycle, your risk will probably cause you to miss it.

A lot of people forget about risk management in agile, I believe that proper story sizing is part of the risk management that teams must be accountable for when becoming a self-empowered, self-managed agile team.

Your thoughts?

Agile Planning...

Two reposts due to their interesting topic and unique content:

• One of my more recent and popular posts was about creating a proper estimate scale. Here is a great post by Bob Hartman about how to improve your poker planning activities. Use it to build on top of my advice!
  
• If you are curious to read a great overview on agile written by a User Experience expert from IBM, I found this quite good. Nothing new for the experts, but I like having good summary resources to leverage when coaching. I also found it interesting since it's coming from such a large company.
  

Create a Proper Estimate Scale...

Tuesday I pointed at Jim Schiel's article about using an abstracted story point scale instead of calendar time (days/hours) for estimation. This morning I read a new article by one of his colleague's at Danube about their issues with their current internal estimation scale.

So, the question is, how DO you come up with a good abstract scale? Here are the main points I believe you need to address when attacking this discussion -

• Atomic unit of measure - the unit of measure needs to be atomic. This means that a value of 2 needs to be 2 times bigger than the value of one. A ten is 10 times bigger than the value of one. Why? so that when you know your team's velocity equals 10 and you select a 1,2,3 and 5 point story for a sprint, you know they actually add up to a sum velocity of 10.
  
• Restrict allowable numeric selections - don't allow just any old number to be assigned to a story. Poker planning estimation decks can't contain every number between zero and one thousand, and you don't want it to. Human brains are very bad at estimating. The larger the estimate, the larger the error. It is easy to state that something will take 1 minute to do... it is very hard to state with confidence whether something will take 60 minutes vs. 62 minutes. The higher your number, the wider the gap between confident values. Most teams use a doubling sequence (1,2,4,8...) or a Fibonacci sequence (1,2,3,5,8,13...). When estimating, you are not allowed to pick a number that doesn't exist in the sequence. Why? it is a waste of time to watch your team bicker over the 12 vs. 13 estimate value on a story when their estimation error is larger than the delta between the two sides of the debate.
  
• Create non-numeric selections - not all estimates can be covered by a value on your scale. Most poker planning decks include a few others. Examples: Question Mark (I don't understand enough to estimate with confidence), Infinity (I understand but it will take longer than we will ever have), Coffee cup (If I don't get a bio. break first, then my estimate will be whatever you want it to be), Zero (it can be done quicker than it will take to have this conversation). Why? This facilitates the conversations that planning and estimation need to flush out. Remember that estimation is not just about predicting, but also about understanding and committing.
• Pick a reinforcing name - pick a metaphor that will invoke interest and understanding. Many people call them points, but some use more interesting terms. Examples: headaches (bigger is bad), donuts (reward I'll get for delivering), dings (times I hit a bell when I deploy), dukets, dolla, goats, bricks, cans of jolt, etc. Why? It not only engages a team, but can put focus on a positive (or negative) part of the process that needs to be used as motivation.
  
• Allow adaptability - remember, this is an abstract scale. It can be adjusted. If after two weeks you find yourself using decimals because you need units under one... then shift your scale. I've done this twice and found two good options. Add a zero (multiply by 10) so that people don't lose reference to the old scale and can transition with ease, or make up a new scale and spend an hour quickly re-estimating the whole backlog. Why? When people have to think about what a value means, then they are losing their ability to do comparative estimation.
  

Feel free to add your comments about other concerns that need to be covered.

Note: If you are interested in other posts about why to use story points, I've also posted about it myself here and here.

Story Estimates...

Story estimates should be estimated in story points... not hours. I'm a strong believer in this. I have been ever since I went through my Agile "conversion" at Siemens Medical. The formal part of my education was mostly provided by Jim Schiel.

From a recent post on the Danube blog by him:

If your estimates are consistently incorrect, you are perfectly predictable.

Click through to read the full post.

Don't abuse the metrics...

Tim Ross blogged about his concerns on burndowns. He offers some interesting points on how they can hurt including:

1. too much pressure early on
2. it doesn't handle the unplanned
3. it is unforgiving
4. PM's and customers misread it
5. it discourages refactoring
6. it focuses on a predetermined time

Hmm.... my responses:

1. really? most people feel it at the end
2. it is a reminder of the reality of the clock
3. neither is the market, it is changing whether you deliver or not
4. well... yes, that's true with any data point
   
5. not if you refactor constantly
6. or you could say it focuses on meeting a completion of commitment
   

Okay... some of that is me playing devil's advocate. I can relate to some of the points that Tim makes. Unfortunately, he proposes a solution where teams focus on the task board and maybe even hide the burndown for only the manager's eyes.

Umm... no. If you are really interested in going agile, then you have to understand that there is a power shift from the managers to the team. Instead of having people above (who aren't doing the work) ask for ridiculous things and make useless statements, the team is now more in charge of the process. But, the idea of a self-empowered, self-managed team is that the team has to be willing to be accountable for the work. This is not just the validation and quality of that work, but also the predictability of its timely delivery.

My view on this matter is two-fold:

• The burndown is an indicator. Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (be it the developers, customers, or managers), then everyone should know about it (that is why we do sprint planning and sprint review together, right?).
• ANY METRIC can be abused. If your culture stinks, or there isn't a trusting relationship between the team and the customer or managers... then any metric can be abused to support finger pointing. This is not specific to the burndown.
  

This is why many waterfall projects fail. It takes so long to uncover problems that when they are realized by lower management, they can delay the discovery further by gaming the metrics and reports to protect their jobs as long as possible.

"My definition [of agile] is that you accept input from reality, and you respond to it" - Kent Beck

A burndown is one of many measurements of reality! Unfortunately I think the answer in this situation is that the group needs to improve the cultural issues instead of throwing out the burndown.

Agile Risk Planning...

I'm going to oversimplify a lot of things in this post. I'm doing it for two reasons... it's not the most interesting topic, and I'm really just trying to throw out a very basic solution to what can be a very complex process. Many environments don't even do risk management, so my theory is that something light covering 60% of your needs is better than nothing at all.

What do we know about Risk Management?

Well, we are supposed to do our best to anticipate what might happen and mitigate it. The best way to do this is:

1. make a list of all the bad things that make you lose sleep (or just worry you)
   
2. assign a probability of each happening
3. assign a cost of impact if they occur
   
4. multiply all of the probabilities by all of the costs and get a total cost
5. put that money in the bank (or time padding on the project plan) to protect against it
6. constantly manage the list to your best knowledge
7. make decisions about how to spend resources to mitigate or remove risks (if you can do this for a fraction of the cost of it actually happening)

Your approach to this could be very scientific, thorough, and accurate... or you could just make some quick gut calls.

What is the agile solution I propose?

First, I believe that the amount of time needed to be invested in this process to make it very accurate is an amount of time and resources that most teams don't have. This is the same issue as estimation for stories and tasks in agile. There's a reason we do poker planning, and it think it might apply here.

1. Let's start with the basics... have the team spend a few minutes each release (every few sprints) brainstorming risks with the guidance of a PM and the PO. The PM, PO, and Scrum Master should have already pre-seeded the list to speed things up since this isn't the main focus for the team.
2. Now assume the risk will occur. Have the team estimate the impact of the risk using the same scale you estimate stories by.
3. Using poker planning, assign a probability of each happening (but use a scale of 1%, 10%, 25%, 50%, 75%).
   
4. Multiply each of the probabilities by its corresponding cost and sum for a total cost. This is your risk budget.
5. Here's where I assume you have an electronic version of your backlog (be it excel, or a tool like VersionOne). Add a story to the bottom of your backlog called Risks. Under it, create a task for each risk. Put your total risk budget as the story estimate.
6. Go.
   

Your system should include this story in any projections it makes for the burndown chart... so now you have that buffer built in to your projected product backlog. You have hedged your bets against the risk odds, and your are reasonably protected without being overly protective.

Responsibilities moving forward:

• Management is responsible for keeping this list up to date. Add/Remove risks as appropriate.
• Any work that can be done to reduce or remove items in this list at a fraction of the cost of the risk occurring should be pursued.
  
• The team should re-estimate both probability and impact cost periodically based on their updated knowledge (this supports the cone of uncertainty philosophy)

That's it... that's my poor man's soluton. Time to apply it and see if it is "just enough".

Final Note- Since I'm not as experienced in hand's on Risk Management as I could be, I welcome any ideas or feedback on this post... especially errors in my thinking. Feel free to beat me up. Most of the places I've worked, I haven't had time to focus on risk because the biggest issue is teaching people how to make and follow a plan along with communicating well as a team (hence my interest in agile).

Update (11/25): Here are two very good articles by James Shore about risk management and estimate inflation if you want to see a more in-depth look at these topics.

Story Pts vs. Capacity Hrs...

I was participating in the VersionOne user forums and a question was being asked about capacity. I'm guessing the person was a scrum master or project manager and they were asking about whether they should plan their resource ideal capacity for 8 hour days or 6 hour days.

This is a question that comes up from managers a lot, but it sometimes gets confused with velocity. I've seen people thinking that sprint planning is based on understanding a teams capacity and scheduling to it. Though there is some overlap and dependency between these two concepts... here is some clarification.

Philosophically, you want to use story points and velocity to plan your sprint commitment. You want to use hours and capacity to measure how you track towards that commitment throughout the sprint. Thus, you are better planning capacity at a realistic level. If for your group that is 6 hours, then plan 6 instead of 8. Teams that do support work in addition to project work typically have a lower capacity. This will vary by team.

In other words, hours shouldn't be used to plan and commit to a sprint. Remember that estimates are faulty and full of human error. The point of story points is to normalize this error out. But, using hours throughout the sprint to track tasks and watch trends is a good way to raise red flags and work with the team. This balance is part of the magic provided by the scrum master and project manager.

This is where the old style PM asks, "what about known vacation and holiday issues?"

Yes, you obviously don't let the team commit to the same amount of story points as the last 3 sprints (your velocity) if you know they are all taking 2 days off for Thanksgiving. But a simple rounding math formula can help you figure that out. Determine the percentage of capacity lost (rounded in days) and remove that percentage from your expected velocity for the upcoming sprint. That simple approach will probably be 85% accurate or more. Any more time spent figuring it out will not improve your numbers enough to be worth the investment.

Update (11/25): Mike Cohn just posted today along these same lines.

Are we there yet?

Are we there yet?
Are we there yet?

Have you ever been driving and heard this from the back seat? I don't have kids that are old enough yet, but I've seen it in the movies plenty of times and am not looking forward to it.

I once found myself saying this when on a flight to Japan. 13 hours on a plane will make you go a little batty. The thing that saved me was the projection on the wall showing the plane relative to the earth with a miles and minutes countdown to landing. Every time I asked myself if we were there yet, I had the answer right in front of me.

When the jetstream shifted and the flight was delayed, this was immediately shown on the screen with the new projection.

Sound familiar? Sounds like a burn-down chart to me (minus the history).

When the plane first took off, a projection was made immediately even though we hadn't made any progress yet. How'd they do that? Sounds like they used yesterday's travels to determine velocity.

When I download software from the internet to my computer, it gives me a sense of how much is complete and how much time remains. This is constantly adjusted as more pieces and packets arrive.

All of these methods make more accurate projections as progress is made.

In some form, ever since we've had the ability to provide this type of feedback on planes, gps devices, software downloads, etc... we've been staring the burndown concept in the face. Why did it take me so long to want this in my daily job?

Low Hanging Fruit...

I've worked with product owners or customers that complain that marking an item on the backlog as low priority instantly sends it to the graveyard to live for eternity and never return. They know that the branding, design, and usability issues on the site are cheap to fix but are not important enough to prioritize in isolation.

Solution?

When you have enough, group them together. Have a story that is "improve the experience of your sign-up process". Lump all those design, usability, and branding bugs into one story and make the team bang through them. (Of course, maybe they shouldn't have gotten through acceptance in the first place, but I needed an example and this reflects reality in a couple places I've worked.)

Another option: When the team picks work for a sprint, they pick up a few big stories and typically have a point or two of left over space. Make them pick up some cheap stuff off the bottom. Have them pick based on closeness to other stuff they are touching. Or have them pick based on value. After all, getting $10 of value for 30 seconds of work is slightly better than getting $1000 of value for over an hour of work.

This was the idea behind the first part of my comment about backlog prioritization on vikramadhiman's agile diary blog.

Story Points and Estimation...

It's hard enough to get the developer, analyst, customer combination to work together as an agile team if they aren't used to it. It's even harder to mature to a point where creating a backlog with properly authored stories comes naturally. (Remember that stories are supposed to be independent, negotiable, valuable, estimable/small, and testable)

What about estimation?

Estimation can be a tricky thing, but the agile community has come up with a structure called story points to simplify this and normalize the human error. I was recently involved in some good conversation in the VersionOne user community around how to sell the story point concept to others, and I found a great explanation of how poker planning contributes to this process.

Note to Ulisses Courel, I'd rather my infinity card over your coffee card any day! ; )

Ambler rocks...

He's an industry leader. In my limited experience, there is very little I can add to this. I can't say it any better. I can only sit at the back of the room and look at everyone else to see if they are getting it as clearly as I am.

For those of you who haven't seen his work before, here are my favorite excerpts to entice you to read the full article:

Starting a project- "You don't need anywhere near the level of documentation, or detail for that matter, that you've been led to believe over the years. For example, although you'll likely be asked for an initial estimate, you don't need to spend weeks or months doing detailed requirements, analysis, and design so that you have the input into some form of complicated estimating process. A ballpark estimate will often do, and frankly it is just as accurate as anything you'd produce counting function points or following COCOMO II."

Should you do a project? "An important consideration during Cycle 0 is the economic, technical, operational, and political feasibility of the project. So we ask ourselves if the system will pay for itself; if you have the ability to build the system (or to manage the project if you're outsourcing the effort); if you can keep the system running once it's built; and whether your organization can tolerate the successful delivery of this system."

Cost? Deal with it- "Agile or not, someone is going to ask the questions: "How much is this going to cost?", "How long is this going to take?", and "What am I going to get?". The real answers, respectively, are "As much as you're willing to spend," "As long as it takes," and "Whatever you tell us that you want," but few organizations are willing to tolerate this level of honesty and instead ask for "exact" answers. Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy to show for it. I believe that it is time to admit that we can't predict the future accurately and cast off the shackles of traditional thinking."