In response to "#NoEstimates Part 1: Doing Scrum without estimates"

In response to "#NoEstimates Part 1: Doing Scrum without estimates" at http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/

Sure, estimates are, well, estimated... based on what the person estimating knows at a point in time, the choices are (1) I estimate it it will require "X" to do it, or (2) I can't estimate what is required to do it. I think this comes down to people not wanting to accept that an estimate could be wrong, or not right enough.

I get an estimate when I need car repairs, to make sure I can or want to afford it. My mechanic calls me when he finds something he did't know that will change the estimate, and I decide what to do. If I find over time that my mechanic always under-estimates the cost, eventually I will change mechanics. The average reality should be a bell curve around an estimated value, an estimate is almost never exact, but a statistically acceptable variation is what you should look for.

   Now, such analogies of physical things are problematic when used to describe an aspect of software development. Software is intangible for one thing, and we really haven't been creating it very long to have some good tools like other disciplines (like Engineering) for predicting outcomes; but like everything else, it takes time and money to create it, so the people investing that time and money usually want an idea of how much that investment will be to get what they need. Just saying an estimate is worthless isn't really going to go over well.

    The advantage of software over physical things is that you can indeed create small amounts of it that can be seen to work. Long before 'agile' got its name, a lot of software projects switched from estimates  to time-boxing: give me x amount of resources and the project will deliver what it can in that 'box'. Investor spends a little to see what he can get for that amount. If it looks good, run another time-box. If it doesn't look good, you can stop with only a small investment amount having been spent.

    Lastly I would comment on your statement on what does an estimate have to do with creating good software and a good return on investment. ROI is a funny thing, often very date-specific; delivering great software after a competitor has already done it and captured the market will kill your ROI. Some windows of opportunity are very short; miss them and the return is nil. In these cases, you have to have some way of knowing if you can make the window. Like it or not, an estimate is one way of trying to figure that out. It is these  kinds of situations that will make investors wary of new development and look for packages or services to meet the need. Nothing is perfect  but not being to estimate software development may just lead to no new software being developed.

Business Analysis - what is it, anyway?

Way back in college I had a an economics professor who was a bit radical. I took his Intro to Economics course, and the first thing he said is " The only thing I am not allowed to change is the name of the course, but  what I will be teaching is totally different than what the course description says." And that is what he did.

I say that because sometime between then and now I started this blog and called it "Business Analysis". At the time it seemed to be the best name for attracting readers for what I would write.

Since then, one of the ongoing discussions out here in the interweb is, just what is Business Analysis? What does someone called a Business Analyst do? My usual rejoinder is to re-use of some Bill Clinton's words: "It's the Requirements...dummy." OK, I leave out the "dummy" unless i really know who I am talking to, but that is the essence. Suffice it to say, my answer (repeated many times, which you could see across many linkedin BA groups) has not  settled the issue. And that's OK, one must not assume their opinion will matter to everyone, especially when they have not paid for it (like buying a book or attending a conference).

(An aside: I was in a tourist shop somewhere and it had a little laminated sign that said "Everyone is entitled to my opinion." I bought and put it on the wall in my cubicle... when I still had one.)

So, to get to a point here, I wish I could change the name of this blog to something more specific to Requirements, but so far I find that is not possible on this platform, and I don't want to start a new one and lose followers and such. That is a technical problem, but it illustrates that I want to be more specific about what I post about. I think that could be summarized with a title like "Requirements Discovery". Until I (bother to) sort out the tech thing, just think of that name when you come by this blog.

So, if you are reading this post because of it's title, I will admit that I did not specifically answer the question; I can only opine on what I think it is: that its core is Requirements Discovery, Description, and Documentation and, despite what else a Business Analyst is asked to do (project manage, test, etc), BAs are the only people/role that has this focus.I don't mean to restrict the scope of what anyone thinks Business Analysis is, but I say if you are not doing Requirements work, then you are probably doing something other than Business Analysis.

Follow-up to “So, you’re buying a package? Don’t forget your business requirements…” Don’t over-analyze!

Follow-up to “So, you’re buying a package? Don’tforget your business requirements…” Don’t over-analyze!

For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement  statements.

1) The system shall determine if a person ordering pizza is a current customer.

2) The system shall determine if a person ordering pizza is a current customer, only if the person is phoning to place an order.

3) The system shall determine if a person ordering pizza by phone is a current customer using the person’s name and phone number.

Each requirement is at a certain level, increasing in detail from (1) to (2), and from (2) to (3).

- Requirement (1) is at high-level, stating that the system shall do something with certain information.

- Requirement (2) is more detailed, stating that the system shall do something with certain information, in a certain situation.

- Requirement (3) is fully detailed, stating that the system shall do something with certain information, in a certain situation, according to certain rules.

Requirement (3) is what you need to provide to designers/developers to use in new software development. However, this not what you need to provide to vendors when you send them an RFP; in fact, this level of detail can be over-kill analysis and can restrict the number of vendors who could meet your needs. By being very specific about rules and restrictions, you may eliminate a vendor who has a different and possibly better approach to meeting the business need, e.g. a better way to determine who is a current customer.

So what level of detail do you need? High level requirements like (1) can be useful at the start of a project, to describe scope and support planning; this level can also be used in a Request for Information (RFI) sent to vendors, just to get an initial view of what the marketplace looks like.

When you get to an RFP, you need more detail to differentiate vendors better, and Requirement (2) is an example of this level, which I call mid-level or standard-level of detail for requirements. At this level, you can see the difference between vendors in meeting your requirements, enough to evaluate their product and decide which one will serve you best.

So I now have two recommendations for organizations looking to buy a package:

- Don’t forget your business requirements…

- … but don’t over-analyze your needs,  so you can best evaluate those packages.