Just got off a project where everything was specified by the customer as one liner requirements. System shall do this. System shall do that. Such old school gathering of requirements shows the lack of understanding what a customer really needs and what adds business value.

Here how software development falls apart right from the beginning. First, there is no realistic way to track metrics. Second, the business analyst have to string together what “they” think are the processes. Many requirements are likely never defined but should be or implied. No way to track that either.

Here is an example building a house to illustrate a point:

House shall have 3 bedrooms
House shall have 2 bathrooms
House shall have a kitchen
House shall have 4 electrical outlets in each room
House shall have a family room

Ok, the the analyst spends time putting together the specs and then reviews it with the customer.

Customer response:

Why am I walking through a bedroom to go from the kitchen to the family room?
Where is the shower? I said we need 2 bathrooms! (yeah but you said bathrooms, I didn’t know if you meant half-baths or full-baths)
Why are all the electrical plugs on the same wall?

This goes back and forth and then you get to the front of the house and all the subjective stuff comes into play such as what kind of door, windows, colors and it goes on and on.

So what is wrong with that? It is terribly inefficient. Once more it is a guessing game for the analysts to interpret what the customer wanted and sometimes the customer needs to be saved from themselves. Customers tend to ask for the moon when a 1 acre plot will do.

Also on the metric front, it adds no value and has no meaning. I have 200 one-liner requirements and they get broken down into 40 use cases. Some of those requirements are shared across multiple use cases. So what is the point is tracking how many requirements are complete? You could to have the PM map it all out and spend the better half of the week trying to build a burn down chart for the last week? Who cares about last week! What about this week? If I have one use case that has a single requirement that takes 30 hours to implement and another use case with 10 requirements that takes 30 hours to complete are you going to build a project plan based on the velocity of 11 requirements a week? What happens if I schedule 11 of the 1 requirement use case’s that take 30 hours to complete each? Worthless metric.

So what is the solution? Well I believe small incremental builds that continually add business value is the way to go. Agile development has been working well in that regard for years but it is not is not without issues. Stories written by product owners are either well done or not much better then the one-liner system shall requirements.

I will be discussing the requirements gathering topic in follow up articles. So what works in your shop?

Don’t you hate gathering metrics that don’t mean anything? In the 80’s it was KLOC (thousand of lines of code) in the 90’s projects got so big we had to do big bang waterfall estimates where nobody had a handle on how long it would REALLY take to complete a project. Now in the agile age we have story points but management still wants hour estimates so they can answer, “when is this done?”

All of these methods have issues with dealing with the unknown, risk, interruptions, attrition on and on and on.

I do like story point estimates. SCRUM and Paceline as well as other agile methodologies do estimate based on story pointing. A customer or product owner would describe an end user feature. The team would then apply a story point to the feature. One common method is use a fibonacci sequence of 1, 2, 3, 5, 8, 13. This was really effective and development teams would quickly have the same feel as to a story point based on amount of work, complexity and risk. Stories that were larger then 13 probably were too complex or too broad and would have to be either broken down or the product owner would rewrite the story. It is amazing how quickly the team sizes the story pretty much the same way.

Story point estimates are great because:

• They incorporate complexity and risk
• They are decided by the team
• Easy to size up an iteration once you have team velocity (number of story points complete in a cycle)

Where story points fall down:

• Management erroneously attaches hours to story points

Great article on story points vs hour estimates I recommend reading blog post from Jeff Sutherland Story Points: Why are they better then hours?

To address the deficiencies, the backlog is complete can be calculated by velocity of the team. Velocity of the team is known after several cycles have been completed. But then all the management what-if scenarios start being asked:

• What if I add this team member?
• What happens it this team member leaves or get reallocated?
• How many folks do I need if I want the backlog complete by 2nd quarter?

SCRUM tools out there do not do a good job providing this information so management and product owners can make decisions. There are other variables such as heads down time of the developers versus meetings they are attending but not coding.

Development metrics are not enough, I believe team management metrics are also in order and should be captured. Beyond story metrics, velocity should also be combined with:

Code blocks per week
Hours of coding per week
Average hours per code block

Why I think this is important is we all know interrupt driven development is unproductive. A developer working one block of 4 continuous hours will be more productive then a developer that works 4 blocks 1 hour each with meetings in between each block. Now here is a metric that management should focus on! An optimized work day for developers will have a higher velocity then an one that interrupt driven.

I would put forth that this should be measured by role: Team Lead, Developer, Test Plan Writer, Test Executor, etc.

Now if we had those metrics combined with velocity we can see how long it will take to finish this backlog of 50 stories and we now have metrics to make management decisions to try and make the team a productive as possible.

What metrics have you found to be useful?

We bought a home in Fuquay Varina that is 20 years old and we knew it was going to take some work to get it where we want it to be. One of the items on the list was the deck that was build to wrap around the above ground pool. My estimation was the addition to the deck was a do-it-yourself job by the previous owner. The wood was splintering, the rails were rickety and very much out of code. The rail posts were only 4×4’s and not very steady. The kids were constantly getting splinters in the feet and because it got so much sun during the day, nobody would go out there until late afternoon or evening. The deck also got very hot as it was in constant sun. We would not go out there until early evening.

We had Rick Ransom, that built and remodeled homes around Raleigh, Garner, Apex, Cary, Holly Springs and Clayton area, put together together a plan to take care of our problem areas. We didn’t like the fact that there was not an edge piece around the pool which made quite uncomfortable to sit on the edge and dip your toes in the water. We also wanted to cut down the amount of sunlight on the back deck. We also would like storage so pool cleaning equipment was not laying all over the place.

Rick did an incredible job. We have bench seats around the pool that doubles as storage for the pool equipment. Rick designed a shadow box over the main part of the deck with an outdoor ceiling fan to keep the air moving. Lattice work on the side also help cut down the sunlight but still lets the air move around. The edge board bent around the pool looks great and keeps the board edges from poking and scraping as you sit on the edge of the pool. The posts are strong with chippendale rails that look great! Rick did an incredible job and I highly recommend him!

If you have a remodeling or new addition you will not go wrong with Rick Ransom. He use to build houses until the bubble popped. So no project too big or small. Give him a call at 919-369-6370 to get quotes on your project if you are in Raleigh area.

You can see more images (before and after) at http://www.facebook.com/album.php?aid=184985&id=607962134&l=bc70f64903

Before

After

The Sony Vaio VPCCW17FX uses the Realteck ALC262 codec and out of the box Ubuntu 9.10 the internal microphone does not work.  However the mic input jack does work.