How long is that going to take?

Sometimes when I get this, I just want to laugh. Other times, I want to cry. How long is this going to take? How should I know? This is the first time I've seen this project, there is no functional spec, there are no requirements, and there is no acceptance criteria. Having this information should be simple and a matter of course, right? It's all about managed, purposeful communication that spans from the customer to the developer. The span, however, has several points for potential failure, and failure is something that cannot be allowed to happen, especially when its prevention is so simple!

Requirements

The first big mistake in this process: not getting a complete picture of what the customer needs. There might be a lot of people out there who gather customer requirements and who think that it's a good policy to simply collect them as the product is being built. Nothing could be further from the truth. Down at the other end of this line of communication is a development team who might have two very different philosophies about how they work with user stories built around the requirements you gathered:

1. They go with it and make the changes as they come. More times than not, this leads to sloppy programming, the creation of unnecessary features, and resentment among team members that a set iteration is continually bombarded with change requests.
2. The team simply will not accept any changes during the iteration because the iteration has been set.

In either scenario, you lose, the team loses, and the customer loses. When this happens, the risk of losing that customer increases. This isn't really what you want, right? Good. So here's a rule for you: pay attention to the customers! Elicit what they need. To do that, you need to understand the business case. Psst! That's why you're a business analyst.

Now, let's pretend that the person gathering the requirements has been rehabilitated, and, after reengaging the customer, we now have a very nice collection indeed. In other words, we have pretty much everything we need to define the system we are going to build. There's still more work to do, though: all we have now is a mountain of nouns, adjectives, and verbs. These need to be further organized in two ways: it would be very nice if we had use cases, and, if the complexity warrants, it would as well be nice to have a functional specification.

Use Cases

The requirements tell developers what they need to build. Use cases scope the requirements into neat little packages and additionally tell the developer how the user will interact with the system. In other words, we now know what we have to build and how it is to behave. Not only will properly-constructed use cases add much needed granularity to the features that need to be developed, but they also provide acceptance criteria. Acceptance criteria provides fodder for both unit testing and test cases. When you write your use cases, be purposeful. Spend time on them. Take a scenario-based approach that is ruled by a set of well-defined processes.

When building out use cases, know that there is certain behavior that should be built into any system as a matter of courtesy and professionalism. For instance, when building a single page application, you might want to disable that submit button until the underlying transaction is complete, right? The rest of the use cases will be defined by behavior communicated by the customer. Because of this, the customer needs to be involved in building them, if for no other reason than to confirm behavior or identify gaps in behavior. At the end of the day, you certainly do not want the customer coming back to you while acceptance testing and wondering why this or that behavior is missing.

Functional Specification

Some projects don't need a functional specification. It really depends on its size. My bet is, though, that the more use cases you have, the more likely it will be that you will need one of these documents. Functional specs can be owned by many people. In some organizations, it's the developer; in others, it's the solutions architect. In spite of who owns it, the document will almost always have more than one contributor. Most of the people who will bother to read this article (two out of the three of you), will have seen a functional spec. Lots of people think that these documents are smelly, and the very sight of them elicits an instinctive dry heave. They are full of jargon and tech and diagrams. They look terribly complicated. Why would anyone in their right mind want to write one of these?

I am a fan of documentation. I do not like to write functional specs. I try to avoid them when I can. If a project is not that complicated, I will choose to build the spec into the code with strategically-placed comments. Good enough. If the project is very large and complicated, though, you'd be doing yourself a great disservice by not creating one of these documents. Here's why:

1. A good functional spec will break the project into entities (if there is more than one)
2. A good functional spec will fully lay out all database requirements, including table creation and the full schema behind the tables
3. The aforementioned schema will unequivocally tell you most of what you need to know about the models you will be using in your various layers
4. A good functional spec will distill any business rules that were precipitated from your use cases
5. A good functional spec will define any process flows that you have in a complicated project
6. A good functional spec will place all of what it delivers into the context of the architecture that has been adopted by your shop
7. A good functional spec will eliminate assumptions and identify gaps based on assumptions

There's lot's more, but sometimes I have trouble counting past seven, so I am going to leave it at that. Okay, so maybe now you agree that you might sometimes need to write one of these documents. So who gets involved? A long time ago, a guy named John Donne wrote that no man is an island. Wow, was he right! The biggest mistake I've seen with these documents is that they were written by a single person, and that person was not at all technical. Hint: you can't write a technical document if you're not technical.

If the project is complicated, you are going to require the services of a number of people:

1. Domain experts: I'm talking any number of people here. The question that needs to be asked, though, is "Can this ask be accomplished under our existing domain?" The person who answers this question does not have to be technical. This person simply needs to be highly knowledgeable about what a particular domain can and cannot do
2. Technical people: If the aforementioned domain expert replies that a certain ask is out of scope with the domain under consideration, then your next stop is someone who does have technical knowledge. This can be an architect, a solutions architect, a DBA, or a developer. It could be all of them. The bottom line here is that you are more than likely going to be adding a feature to your domain. As this can be a fairly significant endeavor, you need to collect the details
3. The primary writer: This could be a business analyst, a solutions architect, a developer. It could be any number of people

User Stories

Okay, let's say we have a really nice functional specification written up. In the document, we have taken the use cases, organized them into domains, and added the minutiae to fully describe processes, flows, business rules, inputs, outputs, and so on. In other words, we now have everything we need to start writing user stories. Finally! Even here, though, we have to be careful about how we create these. For a large project, here's how I would organize my stories (or tasks) in an ideal world:

1. Each entity would be associated with an epic, or a parent story under which child stories will be placed.
2. Each child story will be groomed and placed into the backlog.

Not much about time here, is there? You know why? Because I'm confident that I can swag the hours associated with each of the user stories that will be created above. I can do this because I have a functional spec the identifies pretty much everything I need to do. I am confident because that functional spec was built on a solid collection of customer requirements and well-thought-out use cases. There is no ambiguity. The whole project has been reduced to dozens and dozens of small, well-defined tasks, small units of functionality that I can wrap my head around easily. Now I can give you that estimate.

Besides making me happy, though, what has all of this work really accomplished?

1. There is no ambiguity regarding what needs to be delivered. The requirements were gathered as carefully and completely as possible. Because of this, there will be no downstream work interruptions because of forgotten features.
2. There is no ambiguity regarding how the system is to behave. The use cases were well thought out, so the possibility that the customer is going to come back and complain about features is diminished.
3. There is no ambiguity regarding how the system is to be built. The functional specification left no detail out.
4. Creating epics and user stories is now simple. Because the functional spec identified the domains and the details of changes or additions to each domain, the stories can be created fairly quickly, and those who create them can be confident that the tasks created will be manageable.
5. Because the swag on the hours associated with each user story has been simplified, the total hours to complete can be communicated with confidence to the customer. The possibility of friction down the road because of a missed deadline is now diminished. Further, any hours that you would have eaten because of that missed deadline have been minimized as well.
6. Because the user stories are manageable and easily swagged, the team can now actually pay attention to things like burn-down rates and velocity, both of which had no association with reality whatsoever in the imagined system under which we began.

So, are you really ready to ask me how long this project is going to take?