User stories or use cases?

Alistair Cockburn says "A user story is to a use case as a gazelle is to a gazebo".

If you are extremely familiar with both techniques then this makes sense.  If you are not familiar with both then suffice it to say that you can put a gazelle in a gazebo but not vice versa.

A user story is of the form As a <type of user>, I want <some goal> so that <some reason> (see here).  

A use case for withdraw money has many more components to it, and a skeleton of such a use case can be found here.  I develop this skeleton use case in a four part tutorial:

• Part 1: Use case as a dialog
• Part 2: What is an actor?
• Part 3: Adding interface details
• Part 4: Adding application context

The above user story is only a part of the entire use case.  For an ATM, a user story might be As a user, I want to withdraw money so that I can have physical cash.  This user story is only the summary of the withdraw money use case without the details.

User stories come from the Extreme Programming methodology. The assumption was that there will be a high degree of interaction between the developers, and the end customer and that QA will largely be done through test driven development.  It is important to realize that Extreme Programming does not scale.

Once your development team gets large, i.e. you have 3+ agile teams and your code base gets large enough to warrant a formal testing environment, then you will outgrow user stories as your only method of capturing requirements.

You can still use user stories for new modules developed with an end customer to take advantage of the light weight and rapid nature of user stories, but at some point those user stories should transition to use cases.

Unfortunately, there are quite a few ways to build use cases and not all of them are effective.  Alistair Cockburn's method (found here) is an excellent way to capture use cases for more sophisticated systems.  There is no doubt that use cases are heavier weight than user stories, but consider this:

• Use cases can more easily be turned into test cases by QA
• With use cases you more easily prove that you have all the requirements
• Use cases annotated with screens and reports can be used to collaborate with remote off site customers
• Well written use cases can easily be broken up into a sprint back log
• Use cases will work if you are not using Agile development methods
  

So don't forgo the speed and dynamic nature of user stories, just recognize that there are limits to user stories and that you will need to transition to use cases when your project team or application grows.

Agile tools do NOT make you Agile

Ask yourself the following questions:

• Do great golf clubs make you a great golfer?
• Does a formula one race make you an expert driver?
• Do great development tools make you an expert developer?

Unless you are delusional, you know that the answer is NO to all these questions.  An expert's performance can be dramatically improved with the right tools, but a beginner will not perform better with a great tool.

No matter how Agile-enabled tools like Version One and JIRA become, using either tool will not make you Agile unless you understand what processes make agile development work.

I recently finished a contract at a large retailer where they use JIRA for an enterprise integration project. It was interesting to hear them use terms like sprint and back log; interesting because there was no regular sprint cycle, and the back log was only the tickets in the JIRA system.  JIRA supports the notion of user stories (epics and stories) yet neither of these were being used correctly.

The problem isn't  JIRA; the problem was that they believed that their process was Agile because JIRA supports agile development.

Being agile is about following the Agile Manifesto.

Agile software development is not informality. Agile development has fewer formal practices than traditional waterfall development and those formal practices need to be adhered to (see Agility is not informality).  Agile development is light weight because it avoids activities that are unnecessary to the production of working code, not because it avoids rigour and formality.

There are implementations of Scrum and XP that WORK and are agile because they implement sound development processes.  However, there are also plenty of organizations that are implementing Scrum and XP incorrectly (see Does Agile Hide Development Sins?)

Agile does not dictate that you have a fixed development CYCLE, but you can definitely succeed with one.  What is required is that you break a project into multiple cycles where you iterate on development.
Agile does not dictate HOW you keep your requirements (back log or stories) but you must have an effective requirements process.  If your requirements process is broken then you will never succeed with agile.

The Agile Manifesto puts the priority on things critical to development:

• Individuals and interactions
• Working product
• Customer collaboration
• Responding to change

However, agile does not reject things in the right hand column, unless they get in the way of the above factors:

• Processes and tools
• Comprehensive documentation
• Contract negotiation
• Following a plan

In particular, don't get get caught up in Processes and tools, i.e. Version One and JIRA.  These tools can help you if you understand the core principles of agile development.  If you don't, then these tools will leave you worse off than before.  Unfortunately, the popularity of agile development has every tool maker scrambling to change their product to support agile.

Tools will never extract or synthesize quality requirements and build quality code.  The only way to get to proper understanding of a project is to put priority on individuals and interactions; people and communication are the only way to solve problems -- tools are a secondary concern.

Individuals and interactions OVER processes and tools

Agile development does not dictate a fixed development cycle, but it does require that any cycle must finish with a working product.  The emphasis always has to be production code and that is why periodic demonstrations of working code are essential.

To accomplish this you need to understand your requirements, whether you have a back log or user stories.  There are many times when properly written use cases can be used.  Either way the requirements need to be correct and consistent, they need to be what the customer need, i.e. avoid hiding behind excessive documentation.

Working Product OVER excessive documentation

There is no way to get the requirements correct unless you have a strong working relationship with the customer.  The customer often does not get the initial requirements correct and often development does not understand them.  Focus on customer collaboration is the key to mutual understanding.

This is where most projects fall apart because both parties have a tendency to focus on contract negotiation. Contracts are necessary, but focusing on limiting liability and protecting yourself will not yield a relationship that leads to working software.

 Customer Collaboration OVER contract negotiation

You have to understand that following a plan does not make sense when either requirements or technical uncertainty causes you to change development direction due to the need to respond to change.

It means making reliable estimates up front of all requirements, not just caving into pressure from upper management (see Why Senior Management Declared Deadlines lead to Disaster).  This often means adding time to the projected end of the project when new requirements are discovered or technical challenges force work arounds.  Unfortunately, many projects do not re-adjust the projected end date under these circumstances, which leads to a death march project (see Death March Calculus)

Responding to change OVER following a plan

Agile development is about producing quality software by understanding the principles of the Agile Manifesto.  Agile development is not about deluding yourself simply because you are using a tool that supports agile development.  You can implement a very solid light weight agile solution using only spreadsheets.

Focus on being Agile first, then go find a tool

Other things that are compatible with agile development:

• Comments are for losers
• Inspections are not optional
• Bug Tracker Hell and How to Get Out

Size Matters

Some say that software development is challenging because of complexity. This might be true, but this definition does not help us find solutions to reduce complexity. We need a better way to explain complexity to non-technical people.

The reality is that when coding a project size matters.  Size is measured in the number of pathways through a code base, not by the number of lines of code. Size is proportional to the number of function points in a project.

There are many IT people that succeed with programs of a certain size and then fail miserably when taking on programs that are more sophisticated.  Complexity increases with size because the number of pathways increase exponentially in large programs.

Virtually anyone (even CEOs :-) ) can build a hello, world! application; an application that only has a single pathway through it and is as simple as you can get.  Some CEOs write the simple hello, world! program and incorrectly convince themselves that development is easy. Hello, world! only has a single pathway through it and virtually anyone can write it.

main() {
     printf( "hello, world" ); 
}

If you have an executive that can't even complete hello,world then you should take away his computer :-)

Complexity Defined

As programs get more sophisticated, the number of decisions that have to be made increase and the depth of the call tree increases.  Every non-trivial routine will have multiple pathways through it.

If your average call depth is 10 with an average of 4 pathways through each routine then this represents over 1 million pathways.  If the average call depth is 15 then it represents 107 million pathways. Increasing sophisticated programs have greater call depth than ever and distributed applications increase the call depth even because the call depth of a system is additive. This is what we mean by complexity; it is impossible for us to test all of the different pathways in a black box fashion.

Now in reality every combination of pathways is not possible, but you only have to leave holes in a few routines and you will have hundreds, if not thousands, of pathways where calculations and decisions can go wrong.

In addition, incorrect calculations or decisions higher up in the call tree can lead to difficult to find defects that may blow up much further away from the source of the problem.

What are Defects?

Software defects occur for very simple reasons, an incorrect calculation is performed that causes an output value to be incorrect.  Sometimes there is no calculation at all because input data is not validated to be consistent and that data is either stored incorrectly or goes on to cause incorrect calculations to be performed.

We only recognize that we have a defect when we see an output value and recognize that it is incorrect. More likely QA sees it and tells us that we are incorrect.

Basically we follow a pathway that is correct through nodes 1, 2, 3, 4, and 5.  At point 6 we make a miscalculation calculation, and then we have the incorrect values at points 7 and 8 and discover the problem at node 9. So once we have a miscalculation, we will either continue to make incorrect calculations or make incorrect decisions and go down the wrong pathways (where we will then make incorrect calculations).

Not all Defects are Equal

It is clear that the more distance there is between a miscalculation and its discover will make defects harder to detect.  The longer the call depth the greater the chance that there can be a large distance between the origin and detection, in other words:

Size Matters

Today we build sophisticated systems of many cooperating applications and the call depth is exponential with the size of the system.  This is what we mean by complexity in software.

Reducing Complexity

Complexity is reduced for every function where:

• You can identify when inconsistent parameters are passed to a function
• All calculations inside of a function are done correctly
• All decisions through the code are taken correctly

The best way to solve all 3 issues is through formal  planning and development.Two methodologies that focus directly on planning at the personal and team level are the Personal Software Process (PSP) and the Team Software Process (TSP) invented by Watts Humphrey.

Identifying inconsistent parameters is easiest when you use Design By Contract (DbC) , a technique that was pioneered by the Eiffel programming language. It is important to use DbC on all functions that are in the core pathways of an application.

Using Test Driven Development is a sure way to make sure that all calculations inside of a function are done correctly, but only if you write tests for every pathway through a function.

Making sure that all calculations are done correctly inside a function and that correct decisions are make through the code is best done through through code inspections (see Inspections are not Optional and Software Professionals do Inspections).

All techniques that can be used to reduce complexity and prove the correctness of your program are covered in Debuggers are for Losers.  N.B. Debuggers as the only formalism will only work well for systems with low call depth and low branching.

Conclusion

Therefore, complexity in software development is about making sure that all the code pathways are accounted for.  In increasingly sophisticated software systems the number of code pathways increases exponentially with the call depth. Using formal methods is the only way to account for all the pathways in a sophisticated program; otherwise the number of defects will multiply exponentially and cause your project to fail.

Only projects with low complexity (i.e. small call depth) can afford to be informal and only use debuggers to get control of the system pathways. As a system gets larger only the use of formal mechanisms can reduce complexity and develop sophisticated systems. Those formal mechanisms include:

• Personal Software Process and Team Software Process
• Design by Contract (via Aspect Oriented Programming)
• Test Driven Development
• Code and Design Inspections

To be, or not to be... Formal

What the heck is a formal process?  Is it in the category of you know it when you see it?

A formal process is a methodical way of tackling any repetitive process so that it can be handled in a standardized way.  The idea of formality is to reduce variation in output and minimize the chance of forgetting something.  Formal processes include the ideas of studying, planning, measurement, and process refinement; they cost more and take longer than just just jumping in and getting things done.

Imagine if they tried to make cars in an informal way

Informal, or not formal processes, are faster and cheaper because you get rid of the overhead of a formal process.  It makes sense to be informal when the variation of the process output is not very sensitive to studying, planning, measurement, or refinement.

We are all familiar with trying to use formality when it makes no sense, you simply end up with process for processes sake and waste time and money.

In software, formality has become synonymous with documentation, and frankly we all hate documentation. We don't like to produce it and we don't like to read it.  I've instructed hundreds of engineers and only a few people bother to read the requirements brick.  The way education is going right now I'm not even sure that university graduates can read anyways, but I digress... :-)

For example, documentation for requirements, design, and testing is the end result of a formal process, it is not the formal process itself.  It is smart not to produce more documentation than you need, but that does not mean that the formal processes that creates the documentation are optional.

Formal processes in software development cluster around two very simple ideas:

• getting the correct requirements
• elimination of defects

The problem is that formal processes only work when you do enough of them to make a difference.  That is not doing enough of a formal process is just as bad as doing too much.  For example, UML class diagrams will not only help you to plan code but also educate new developers on the team.

Producing UML diagrams is a formal practice; however, if you insist on producing UML diagrams for everything then you will end up spending a significant amount of time creating the diagrams to get a diminishing benefit.  Not having any UML diagrams will lead to code being developed more than once simply because no one has a good overview of the system.
Selective UML diagrams can really accelerated your development

Visualizing Formality

As you increase any formal practice the effect of that practice will increase, for example the more formal you are with UML diagrams the less defects you are likely to have:

However, as you increase formality, the costs of keeping track of all your artifacts goes up:

When you put the two graphs together you get this effect:

This shows that there is a cost to not having enough formality, i.e. no UML diagrams means that more code will get developed and less reuse means more defects.  However, producing too many UML diagrams will also have the cost of producing the UML diagrams and keeping them updated.  The reality is that for any formal practice there is a sweet spot where the minimal formality gives the lowest cost.

What that means is that productivity will be maximized in the sweet spot.

Remember that most formal practices are hygiene practices, these are things that no one wants to do but are really necessary to be highly productive and produce high quality code (see here for more on hygiene practices)

Statistics Behind Formal / Informal Practices

Formal practices can be applied to many things, but Capers Jones has measured the following formal practices (when properly executed) can have a positive effect on a project (15,000+ projects): 

Formal risk management can raise productivity by 17.8% and quality by 26.4%

Formal measurement programs can raise productivity by 20.0% and quality by 30.0%

Formal test plans can raise productivity by 16.6% and quality by 24.1%

Formal requirements analysis can raise productivity by 16.3% and quality by 23.2%

Formal SQA teams can raise productivity by 15.2% and quality by 20.5%

Formal scope management can raise productivity by 13.5% and quality by 18.5%

Formal project office can raise productivity by 11.8% and quality by 16.8%

A special category of formal practices are inspections:

Formal code inspections can raise productivity by 20.8% and quality by 30.9%

Formal requirements inspections can raise productivity by 18.2% and quality by 27.0% Formal design inspections can raise productivity by 16.9% and quality by 24.7%

Formal inspection of test materials can raise productivity by 15.1% and quality by 20.2%

More information on inspections can be found here:

• Software Professionals do Inspections
• Inspections are not optional

Not being formal enough has its costs, and it is rarely neutral.  Here are some of the costs of not being formal enough:

Informal progress tracking can lower productivity by 0.5% and quality by 1.0%

Informal requirements gathering can lower  productivity by 5.7% and quality by 8.4%

Inadequate risk analysis can lower  productivity by 12.5% and quality by 17.5%

Inadequate testing can lower  productivity by 13.1% and quality by 18.1%

Inadequate measurement of quality can lower  productivity by 13.5% and quality by 18.5%

Inadequate defect tracking can lower  productivity by 15.3% and quality by 20.9%

Inadequate inspections can lower  productivity by 16.0% and quality by 22.1%

Inadequate progress tracking can lower  productivity by 16.0% and quality by 22.5%

N.B. progress tracking is on the list twice.  Informal progress tracking is fairly neutral, but inadequate progress tracking is deadly.

Conclusion

In development practices it is not a matter of formal vs informal.  It is a matter of seeing what kind of variation that you are exposed to and recognizing that formality can make a difference in that area.  Then it is a matter of only adding as much formality as you need to get maximum productivity.

Formal practices must be monitored, you must have some way of testing if the formal practice is having an effect on your development.  You want to make sure that you are executing all formal practices properly and not just going through the motions of a formal practice with no effect.  You must monitor the effects of formality to understand when you are not doing enough and when you are doing too much!

---

Articles in the "Loser" series

Moo?

Want to see sacred cows get tipped? Check out:

• Comments are for Losers
• Efficiency is for Losers
• Defects are for Losers
• Debuggers are for Losers
• Not Planning is for Losers
• Testing departments are for Losers

Make no mistake, I am the biggest "Loser" of them all.  I believe that I have made every mistake in the book at least once :-)

Agility is not Informality

Agile Formality:A “  Mole ” of Software Engineering Practices

Agility is about following the Manifesto for Agile Software Development, not the sloppy and crazy implementations of Scrum, XP, or other home-grown schemes out there. Sometimes I feel like people are using Agility as an excuse to be informal. Two of the key principles of the Agile Manifesto are: Working software over comprehensive documentation Responding to change over following a plan

Somehow some developers have interpreted this as meaning that there are no formal processes to be followed. But just because you are putting the priority on working software does not mean that there can be no documentation; just because you are responsive to change doesn't mean that there is no plan.

Agile development when properly implemented can accomplish great things.  When it is just an excuse to be undisciplined and cover-up cowboy development then a so called 'Agile' process will work very poorly and the organization will just spin its wheels.

Agile development in general raises productivity by 18.2% and quality by 27.1%

Extreme programming (XP) specifically raises productivity by 12.8% and quality by 17.8%

Agile software development does have formality and it requires quite a bit of discipline to stick with it. A few formal practices include:

• Stand-up meetings
• Work burn down charts
• Sprint demos
• Simplicity
• Improvement through reflection

Stand-up Meetings
Stand-up meetings are an integral part of the Scrum process and is a key discipline of Scrum, when they are done properly. This meeting is a coordinating mechanism of a self-organizing team where each member states:

• What have they finished
• What are they working on
• What external issues do they need help on

The scrum daily meeting raises productivity by 16.4% and quality by 23.5%

Believe it or not, there are some Scrum teams that sit down for the stand-up meeting. What the heck is this? The purpose of standing up is to be slightly uncomfortable and keep in mind that the meeting is supposed to move quickly.

You state what features that you have finished so that team mates waiting on your deliverables know where you are at. Finished means that you have unit tested your code (i.e. TDD) and that black box testing can start if there is a tester in your Scrum team.

Automated unit testing raises productivity by 16.5% and quality by 23.8%

You state what you are working on so that other team mates know what you are doing and can organize their work accordingly.  Don't bother to state how you solved problems, that was an issue for planning with team mates before you started coding.

You state what you need help on that is external to the Scrum team so that the Scrum master can resolve the issue.  This is not a design meeting, if there are issues that you need to resolve with team mates then you can resolve this issue right after the meeting.

Burn Down Charts

Work burn down charts is a formal discipline and essential to success (see Who Needs Formal Measurement?).  The work burn down chart is the heart of accountability in Scrum.  For the chart hours to get to 0 on a regular basis, it relies on the principles of: 1) commitment, 2) execution, and 3) estimates.

The point of a self-organizing team is that it commits to work each sprint to get the work done.  If it turns out that they over committed to a sprint then they must do whatever it takes to get the job done.  That may mean extra hours or it may mean being extra creative, but once you commit to work then you have got to get it done.  That means execution, it means doing what you say that you will do.

You may have a sprint or two where the work burn down chart does not go to 0.  If this is happening on a regular basis then you have either an estimation problem or a team commitment problem.  If engineers are regularly underestimating their tasks then it means that you really don't know how long things take.  You should consider some of the techniques in the Personal Software Process (PSP) to improve your ability to estimate.

PSP development raises productivity by 21.3% and quality by 31.3%

Another cause of work burn down charts not going to 0 is that the team is not really self-organizing.  The team needs to commit to the work to be done, it will never work if the organization assigns the work to be done in the sprint.

If you lose discipline during the sprint and don't keep the work burn down charts up to date, then you are not tracking progress correctly.  Remember, you can't manage what you don't measure.

Inadequate progress tracking reduces productivity by 16.0% and quality by 22.5%

Sprint Demos

The sprint demo is not optional, it is a mandatory part of the process.  The sprint demo is to demonstrate near-production code and demonstrate a working system.  The team needs to put pressure on itself that the code must be complete by the end of the sprint; this forces a self-organizing team think through the amount of work that they can commit to.  No demo = no team commitment.

Remember the whole point of Agile development is to put the emphasis on working software.  If you are not producing working software every sprint, then what are you doing? Whatever you are doing it is not Agile development.

The Agile Manifesto puts emphasis on working software.  If your sprints are not producing working software then you are not doing agile development.

Simplicity

The best designs are the simplest designs because they are easier to understand and maintain.  In a previous article No Experience Required! I discuss how years of experience do not make for better programmers.  You might expect that the best developers have more years of experience, but 8 studies over 30 years show that this is not the case (you might even want to get rid of poor performers with many years of experience, but see the article :-) )

In fact two persistent facts about the differences between the best and worst developers is that:

• program execution speed about 10 to 1
• program size 5 to 1

Much of this results from simplicity. The best developers plan their code and write simple and straight forward routines. The are rewarded by having smaller programs that execute quickly. The worst developers do not plan their code and shoot from the hip. They write convoluted code that is much larger and has much worse execution time.

Agility is about simplicity. It is spending 80% of your time thinking and 20% of the time writing simple and elegant code. It is not about spending 100% of your time writing complex and convoluted code that even you can't understand.

Simplicity does not happen, it is planned; it takes tremendous effort to write simple code.  The best developers plan their code (see PSP above) and are continually refactoring their code to make designs simpler to understand and maintain.

Automated restructuring raises productivity by 8.0% and quality by 11.7%

Code refactoring raises productivity by 4.3% and quality by 6.7%

Improvement through Reflection

A key discipline in Agile development is to reflect on what you can do better as individuals and as a team. There is always room for improvement, there is often a better way to do things.  Professional developers are keen to keep learning and improving their craft, and the best way to do this is by reflecting on the sub-optimal choices that we have made in the past and trying to do better in the future.

Conclusion

Agile development is about following the Agile Manifesto, it is not about informality.  True agility is developed by having the discipline to be formal in many things:

• Team synchronization
• Learning to estimate
• Tracking progress through burn down charts
• Committing to create production code
• Planning simple code
• Improving by not making the same mistakes

Agility is about being disciplined and formal in processes that count

---

References

• Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.¹
• Vierie del Bianco and Stosic, Dragan.  Agile Formality: A "Mole" of Software Engineering Practices²

¹N.B. All productivity and quality percentages were derived over 15,000+ actual projects
²Reference courtesy of Michael Jessop

---

Articles in the "Loser" series

Moo?

Want to see sacred cows get tipped? Check out:

• Comments are for Losers
• Efficiency is for Losers
• Defects are for Losers
• Debuggers are for Losers
• Not Planning is for Losers
• Testing departments are for Losers

Make no mistake, I am the biggest "Loser" of them all.  I believe that I have made every mistake in the book at least once :-)

Who needs Formal Measurement?

We all know the expression "You can't manage what you can't measure", but do we really understand it?

After execution, feedback is an essential part of all processes.  Just think about how difficult it would be to drive from home to work wearing a blindfold.  Without your sense of sight to give you feedback on the traffic signals and the locations of other cars you would crash your car.  Yet we develop software systems without instituting formal measurement programs all the time and wonder why we succeed so rarely?  (for success rates see Understanding your chances of having a successful software project)

You can't manage what you can't measure

No measurement means no feedback, which means your chances of success are minimized. Success is possible without formal measurement but it is much easier with formal measurement.

Formal measurement raises productivity by 20.0% and quality by 30.0%

A best practice is one that increases your chance of succeeding, it does not guarantee it. It has been established that formal measurement is a best practice, so why do so few people do it?

Measurement has a cost and organizations are petrified of incurring costs without incurring benefits. After all what if you institute a measurement program and things don't improve?  In some sense managers are correct that measurement programs cost money to develop and unless measurement is executed correctly it will not yield any results.

But is there a downside to avoiding measurement?

Inadequate progress tracking reduces productivity by 16.0% and quality by 22.5%

Failure to estimate requirements changes reduces productivity by 14.6% and quality by 19.6%

Inadequate measurement of quality reduces productivity by 13.5% and quality by 18.5%

So there are costs to not having measurement.  Measurement is not optional, measurement is a hygiene process, that is, essential to any process but especially to software development where the main product is intangible.

A hygiene process is one which can prevent very bad things from happening. Hygiene processes are rarely fun and take time, i.e. taking a shower, brushing your teeth, etc.

History has show that it is much more cost effective to execute a hygiene process than take a chance of something very bad from happening, i.e. disease or your teeth falling out.

There are hygiene practices that we use every day in software development without even thinking about it:

• Version control
• Defect tracking

Version control is not fun, tracking defects is not fun, but the alternative is terrible.  Only the most broken organizations think that they can develop software systems without these tools.  These tools are not fun to use and virtually everyone complains about them, but the alternative is complete chaos.

Formal measurement is a best practice and a hygiene practice

The same way that developers understand that version control and defect tracking is necessary, an organization needs to learn that  measurement is necessary.

Is Formality Necessary?

The reality is that informal measurement is not comprehensive enough to give consistent results. If measurement is informal then when crunch time comes then people will stop measuring things when you need the data the most.

When you don't have enough formality then processes take longer and by extension cost more.  When you have too much formality then you have process for processes sake and things will also take a long time.  Any organization that implements too much formality is wasting their time, but so is any organization that does not implement enough.

When you suggest any formal process people immediately imagine the most extreme form of that process; which would be ridiculous if it is implemented that way. We have all been in organizations that implement processes that make no sense, but without measurement how do you get rid of these processes that make no sense?

For every formal process that makes sense, there is a spectrum of implementations.  The goal is to find the minimum formality that reduces time and costs.  When you find the minimum amount of formal measurement you will accelerate your development by giving yourself the feedback that you need to drive your development.

What to Measure

It seems obvious, but incorrect measurement and/or poor execution leads to useless results.  For example, trying to measure productivity by measuring the hours that the developers sit at their machines is as useful as measuring productivity by the number of cups of coffee that the developers drink.

Another useless measure is lines of code (LOC), in fact, Capers Jones believes that anyone using LOC as a measurement should be tried for professional malpractice!

Measuring the the three things mentioned above will improve productivity and quality because there will not be a negative effect on your organization:

• measuring progress tracking (productivity +16.0%, quality +22.5%)
• estimating requirements changes  (productivity +14.6%, quality +19.6%)
• measurement of quality (productivity +13.5%, quality +18.5%)

Other things to measure are:

• Activity based productivity measures (productivity + 18.0% , quality by 6.7%) 
• Automated sizing tools (function points)  (productivity + 16.5% , quality by 23.7%) 
• Measuring requirement changes  (productivity + 15.7% , quality by 21.9%) 

So to answer the question: who needs formal measurement?

We all need enough formal measurement to get the job done

---

References

• Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.

N.B. All productivity and quality percentages were derived over 15,000+ actual projects

---

Articles in the "Loser" series

Moo?

Want to see sacred cows get tipped? Check out:

• Comments are for Losers
• Efficiency is for Losers
• Defects are for Losers
• Debuggers are for Losers
• Not Planning is for Losers
• Testing departments are for Losers

Make no mistake, I am the biggest "Loser" of them all.  I believe that I have made every mistake in the book at least once :-)