Applying the "80-20 Rule" with The Standish Group’s Statistics on Software Usage

What’s 80-20 rule?

Also known as the Pareto Principle, the law of the vital few, and the principle of factor sparsity, states that, for many events, roughly 80% of the effects (output) come from 20% of the causes (input). In the early 1900’s it was observed by an Italian economist Vilfredo Pareto, that there was an unequal distribution of wealth in his country where 80% of the land was owned by only 20% of the population. While originally pertaining to economics, this phenomena was observed by other professionals in their own areas of expertise.  In business for example, 80% of your sales come from 20% of your clients. In the software domain, many experts note that if you develop 20% of the highest priority features, you’ll satisfy 80% of the business needs. Moving on…

What’s The Standish Group’s statistics on software usage?

Jim Johnson, Chairman of Standish Group, reported at the Third International Conference on Extreme Programming (XP2002) that in typical software systems 64% of features are never or rarely used in reality. This was largely apparent in systems where up-front plan and design were done before business ROI was considered or even knowable. What’s more interesting is that from a positive point of view, 20% of these features are used always or often used!

Merging the two to get the highest return on investment for the business!

So, it should follow that if we can prioritize our requirements (stories) and work on the most important 20% of our backlog (list of epic stories), then we could ultimately satisfy 80% of the business needs. At the same time; once this initial 20% of the features are in production, it will also be used by the business predominantly (always or often). The most important part of doing this effectively is finding that initial 20% of the requirements that return 80% of the clients satisfaction. An valuable Product Owner will be able to prioritize and understand that not every feature is high priority. I believe that the more you understand your business, the easier it is to arrange your priorities. That’s why an effective PO is the foundation of delivering valuable business features.

In Practice:

I’ve witnessed the 80-20 rule apply itself over and over again in our industry and also in my position. Software products developed where an equal amount of effort was put into building low priority features as it was to build the high priority features. At the end of the day, the return on investment was inherently lower on those features which customers rarely or never used or were unimportant. Effort is lost or wasted, which could have been allocated to more important features or features that that will be used more often. If you’re working on a project with unlimited budget then this could be OK, but I’ve yet to see one in real life (nor do I ever expect to).

This is not to say that any feature that is not used often or always is unimportant. Sometimes a feature that is used rarely is important to the business; in that case the priority would be high and likely moved up the priority list. But more often than not, if a feature is used often or always, it is likely to be a higher priority feature versus features that are used rarely or never (obviously). The better the Product Owner, the more fine grain each priority will be.

My humble advice:

If given adequate time on a project, module, or epic story, by working on the highest priorities first, as soon as you reach the most important 20% anything after that is bonus. Continue working on the time-boxed iteration or release plan, delivering beyond the initial prioritized 20% if you can (reach 55%), but remember that your effort-to-results ratio will diminish dramatically the further you go to fulfill 100% of the features. You could move on after the initial 20% to another important module, or work until the time-boxed iteration (fixed amount of money) runs out. A good idea after building the initial priorities is to stop and get feedback. Feedback is a time for the business to learn and for the development team to adjust if necessary. I can almost guarantee that the business will ask for something else that they originally didn’t plan to or have other opportunities come up that change priorities for what is important now.

Focus on the 20% that matters:

It’s not to say that the other parts of the software are not important, but that you’ll get more return for your efforts if you focus on the most important 20%. Here’s an example of how this works:


By working on the highest priority features first, and releasing early the customer has an opportunity to learn from the market (2 pre-releases occur before the project release date). Also the business has a chance to realign it’s next priority needs if necessary. The highest prioritized features are delivered earlier in the project, usually before the project is over or the money runs out. These features are the ones that will be used always or often by the business. An added bonus is that the company can actually start making money (earlier than expected “$” shown on the diagram) during these initial releases. As a consequence the software is bringing income into the project allowing it to partially fund itself. I’ve witnessed many projects partially funding itself first hand so this is not a hypothetical situation. If time/money does run out before the entire product backlog is complete then you’re still in a good position because you’ve already met at least 80% (if not more) of the business needs. In the example diagram above, we’ve delivered over 55% of the features. What’s remaining in terms of features are never used (according to the Standish Groups report on software usage). I wouldn’t go so far as to totally ignore the remaining features, but I would agree that they are far less appealing and less rewarding to work on than the initial 55%.

Prioritize and focus on what matters the most, you’ll see more benefits emerge with less effort. Ask yourself the question “What are the priorities and are we working on the ones that we value the most“. You’ll see it applies to many other aspects of life, not only the software business!

Shortening the Feedback Loop – Our Sprint in a Nutshell

Thanks to everyone who attended the 2008 December Calgary Agile Methods User Group (CAMUG) meeting yesterday. We received a lot of questions during the presentation and good feedback after the presentation. Some people asked for a copy of the powerpoint slides, here it is. The slides don’t tell you too much about the actual content of the presentation because most of it was elaborated by the presenter, but it should give you a good idea of the points. Here is the presentation synopsis:

Under the Agile software development umbrella there are many principles, processes, methodologies, and practices that fit this style of development. Many companies are relentlessly seeking and implementing ways to continually improve how they design, develop and deliver software. We believe and have found in practice that the Agile way of software development enables, supports and drives this continuous quest for efficiency and improvement. One of the primary goals of Agile software development is to satisfy customer needs through early and continuous delivery of valuable software. We find that most of the business value comes from creating an environment where a shorter feedback loop allows our team to be more proactive and adapt quickly as and when necessary. In this presentation we will share and walk you through a typical sprint/iteration at and highlight to where we have shortened the feedback loop and increased efficiency and feedback quality.

See Mo’s blog for pictures of the audience.

Presentation at a glance:


slides outline

Japanese terms for the Agile developer

If you’re interested in knowing about how Toyota became the world’s most profitable car manufacturer then this book is for you!



For more than 50 years Toyota has applied and refined it’s lean manufacturing principals, also called TPS or the Toyota Production System. Without going into the details of this book (for now) here are some Japanese terms I thought would be very suitable for agile developers and the agile community at large.

Kanban – Card or ticket or sign board. Used to signal to the previous step when its part needs to be replenished. Kanban is a signaling system to trigger action. This creates a “pull” system

Heijunka – Level out the work load. A production scheduling and load leveling tool. Distribute kanban cards in an efficient manner.

Muda – Waste or non-value-add work. Eliminate waste or non-value-add is a top lean philosophy and is said to be the focus of most lean efforts.

Muri – Overburden or pushing beyond limits. Overburdening machines causes breakdowns and defects and pushing a person beyond their natural limits causes safety and quality problems.

Mura – Unevenness. Muda will be a result of Mura. Unevenness results from an irregular production schedule or fluctuating production volumes, indicating internal problems. In lean manufacturing you need to balance production volumes.

Jidoka– Built-in quality. Also referred to as “autonomation”, equipment endowed with human intelligence to stop itself when it has problems. Used as a quality control system to build a culture of stopping to fix problems and getting quality right the first time.

Andon  – Light signals or cords that could be pulled for help. Used to stop or warn the production line in a specific section or work center.

Kaizen – Continuous improvement. The process of making incremental improvements, no matter how small, to add value. Defines Toyota’s basic approach to doing business.

Genchi Gembutsu – Go to the source to thoroughly understand the situation.

Nemawashi – Literally translates to “going around the roots” or closely translated as “laying the groundwork”. Discussions between many people giving input and helps everyone to be in agreement when a decision or change is made.

Hansei – Reflection, become a learning organization through relentless reflection. Hansei go hand in hand with kaizen, without reflection you cannot have continuous improvement.

Hoshin Kanri – Policy deployment. Directing and motivating organizational process by cascading objectives from the top of the company down to the work group level.

Sensei – One who provides mentoring, teacher who has mastered the subject.


There’re probably some more Japanese terms in this book that I missed but these ones stood out to me the most. I see many resemblances to Agile Software Development thinking, processes, methodologies, etc. in the terms above. Can you do the agile translation of the of these Japanese words/phrases?

Quick GUI Prototyping Tool for Business Users

Like Firefox 3.0? Need a quick and easy-to-use prototyping tool? Just download this add-on called The Pencil Project for Firefox 3 and sketch away! I wanted a tool that is lightweight and unobtrusive that allows me to quickly sketch my prototypes without the need for visual studio or a similar developer tool. This add-on to Firefox was just that! I was able to get good looking interfaces within minutes of downloading the tool. It’s free, only 400 KB and it’s platform independent. If you (like me) find that other tools out there are too complicated or do too much for your simple prototyping needs then try this one!

Planning Poker Cards For Everyone

I thought this would be useful “swag” for any teams out there starting Agile estimating techniques or any teams who want to improve at estimating development tasks.  I’m not going into the details of how it’s done, you can read for yourself I first read about planning poker in Mike Cohen’s book Agile Estimating and Planning. You can also get actual planning poker cards from his company’s web site, what a great idea!

Back when our team was learning Agile estimating I had these documents made to help us play planning poker. I thought these would be useful to anyone in the learning phase or wants some tools that can help with the process. So here it is, FREE planning poker cards that you can take to your favorite print shop and get printed (download the attached PDF’s).

Planning-Poker-Playing-Cards-pg01_front_thumb Planning-Poker-Playing-Cards-pg01_back_thumb_1

Planning-Poker-Playing-Cards-pg02_front_thumb_1 Planning-Poker-Playing-Cards-pg02_back_thumb_1



Planning Poker Playing Cards pg01_front – Planning Poker Page 1 Front

Planning Poker Playing Cards pg01_back – Planning Poker Page 1 Back

Planning Poker Playing Cards pg02_front – Planning Poker Page 2 Front

Planning Poker Playing Cards pg02_back – Planning Poker Page 2 Back


Then I took this one step further and made use of our company’s business cards which needed to be reprinted anyways! Instead of just getting new business cards printed, why not take this opportunity to make planning poker cards out of them? Dual purpose Agile business cards! The front of the cards have the generic company branding as well as the individual contact information. The back of the cards have our division brand (ThirdAngle) and a unique number used for estimating. It’s also a good conversation starter when you give out your business cards :-).



Next time you see the team you’ll have to ask for each of us for our business cards so you can have the set.

The Time-Value of Agile Software Development

Here’s a good 5 minute video from on the time-value of Agile Software Development titled “Why does Agile Software Development pay?”…




In my opinion, at the point where traditional software development makes it’s first release versus where Agile is at that time (many releases in), I think the Agile value is much higher than the video suggests because of the empirical feedback the end-users have put in along the way and the ability to change quickly based on real-time prioritized business needs. It’s a powerful visual representation of Agile Software Development that businesses wishing to build software, either in-house or using a vendor, should really look into. For businesses that are currently building software, can you ask yourself these questions?

  • Are you able to use and go into production with your software at consistent intervals (weekly ,bi-weekly, or at most monthly)?
  • If you do get software at consistent intervals, are you recommended to give feedback without it costing you more money?
  • Is working software that meets business needs in a timely manner more important than contract negotiation?
  • Are changes in priority and/or features embraced by the development team?
  • Does software development respond to your business changes in a real time manner? The time it takes for your business ideas to be turned into revenue generating software is weeks not months or years?
  • Does communication occur daily between the business and the development team, can it, is it face to face?

If you can answer “yes” to all of these then that’s great, if not then wouldn’t you want to? At least give it a try with an experienced Agile shop to see if your business can achieve a much higher return on investment and client satisfaction.

Scrum Master Training course offered in Calgary


The Certified Scrum Master course doesn’t get offered very often in Calgary but as agile software development becomes more mainstream I am starting to see the course offered more and more. IMHO Scrum is quickly becoming the de facto standard for managing successful software projects today. Check out this course at or  It’s a good introduction to agile project management using Scrum. Scrum is not technical at all since it concentrates on the management side of software projects. But when performed in conjunction with the technical software engineering practices of Extreme Programming, you’ll find they compliment each other very well.

I remember taking the course in the summer of 2005 with Kert Peterson and back then I think there were only around 3000 or so Certified Scrum Masters in the world. I think there’s at least 25,000 registered members now, here is the list of Scrum Masters (mind you not everyone here is practicing it though) You can also get trained in the Practitioner, Coach, or Trainer certifications as well.

This course is entry level (2 days only) so don’t expect to come out an expert. However, it does give you a good basis to start becoming an agile project manager. I would suggest this course not only to project managers, but project leaders, developers, product owners (although there’s a separate course just for PO’s now), and probably anyone in the software management domain who wants to know more about how to run an agile project.

You might be interested in this list of companies that claim to be practicing Scrum for project managing software projects. I say “claim to be” because it could be only a small team in the company that is practicing it, nevertheless some of these companies are very large so it shows how Scrum also scales to large organizations:

Extreme Programming Explained "Embrace Change"


extreme programming explained

I finally got back to some reading after busy weeks moving offices and getting comfortable in the new  environment (I also changed employers!). This book was borrowed for an extended amount of time so I thought it was time to finish it and give it back or pass it on (thanks Mo)…


This is the Second Edition of the book where the author, Kent Beck, takes a lighter less “extreme” approach to introducing Extreme Programming. Still, if you don’t already know the values, principles and practices of Extreme Programming (XP), this book will help you question what you’re currently doing in software development and if it’s truly what you believe is the most humanistic approach. It’s not that this book tries to convince you on doing things a certain way, but rather, Kent Beck portrays values as universal truths then relates them software development through principles and practices that simply make sense. Values like communication, simplicity, feedback, courage, respect, … are some of the most important values of XP. Practices like co-located team members, visual informative workspace, pair programming, continuous integration, test-first programming, … are engineering practices that lead to better software. Then bringing everything together are principles like humanity, baby-steps, continuous improvement, mutual benefit, reflection, flow, quality, …  puts a software development context to the values and gives purpose to the practices that are being performed. All these work together and complement each other and without the values, principles, and practices as a whole the team lacks the true benefit of XP, actually I think it could lead to some very dangerous situations where XP could fail as an agile methodology. Other interesting points I noted in this book are:

  • Identifying the highest priority user stories and building them first will yield the most business value and satisfaction for clients. It only takes 20% of the most important features to yield 80% of the business value (the 80/20 rule).
  • Metrics in XP are different so be careful of how you measure it as compared to traditional business practices (you will get what you measure). Two suggested metrics are defect rate per deployment, and the elapsed time between the start of an investment idea and the time that idea starts generating revenue. I’ve witnessed many one week iterations with our team that demonstrates to our clients that given only a week we can turn their ideas into reality.
  • The Theory of Constraints states that in a system there is one constraint at a time… find it… improve it or offload the workload or remove it entirely. Then move onto the next constraint and do the same.
  • XP uses the “pull” model of developing software where stories are designed in detail right before they are implemented.
  • More time at a desk does NOT equal increased productivity for creative work. Yes, software development is very creative!
  • Plan for work based on past experience (your velocity in the last iteration), and adjust the plan when new information arrives.
  • When faced with a big ball of mud (code design and complexity) begin by improving the design where you walk (lighting the lamp). Consistently performing small improvements is better than one big refractoring iteration where little or no business value is delivered at iteration-end.
  • Members in an XP team share the same fate. Success and failures are shared amongst every member. The whole is truly more than the sum of it’s parts. Realizing the potential in software relies on teamwork. A deep change in values and relationships is encouraged.

Like everything in life, don’t expect a silver bullet to solve your problems or improve your situation. There is no prescription with steps that say “do this… then you’ll get exactly that…”, XP is something you should try then customize it to work for your organization. If it works then keep it and improve it, if it doesn’t work then figure out why and try something else. To me, at the end of the day, XP brings about an empowered software developer who continuously searches for better ways to improve business value. They are able to quickly estimate, implement, and deploy reliable software at incredible consistency. I leave you with a quote from the book:

“Tools and techniques change often, but they don’t change a lot. People, however, change slowly but deeply”

How to setup the simplest collaboration environment?

Agile is truly about simplicity and it is most apparent in the tools and practices our team uses everyday. Take our visual workspace for example, the place where high collaboration occurs on a daily basis. It doesn’t have to be a complex software package like some of the tools I’ve seen in the marketplace (I still have yet to try them all, but I do have a list and a reminder to try them out to see if they have potential). I find that once you put information in electronic format you have to do a lot of management (and reminding) to get people to read it. If you can get away with having it up front and center where everybody involved on the project can quickly and easily find out these 4 pieces of information, then you’ve got it made:

1. What’s planned for this iteration?

2. What’s done so far?

3. What’s remaining?

4. What’s the progress?

If a stranger can walk into the room without prior knowledge of the project, and within seconds know what tasks are complete, what tasks are remaining, and what the progress is… imagine the collaboration this environment would generate for the team and customers working on the project?

So how do you setup the simplest collaboration environment? Well, you don’t have to go to the “outer most reaches of Calgary” to find it, as Adam wrote in his blog. But you do have to put a little sweat into it! Trust me it’s well worth it if you need big custom boards and only want to spend a fraction of the cost. I’ve setup two offices (my old office and just last week my new office)using this environment and will probably do the same for my office at home. Here’s the details:

Whiteboard Purchase:

  • You can go to your favourite home building/renovation store like Rona or Home Depot and look for 4×8 feet sheets of white Tileboard. This material is also called Melamine Tile. It’s typically used to build shower stalls, but the finish is basically the same as regular whiteboards found at office supplies stores. Make sure the surface is smooth and glossy (and bring a dry erase marker to test, I didn’t tell you to though). The board will run you about $72 each. You’ll need a truck (thanks Joel) with a 6 foot bed because these 4×8 sheets don’t bend very well.



image_thumb image_thumb_8 image_thumb_9

Counter clockwise from the top left of the first picture: 3 foot level, tape measure, hammer, two sided tape (holds down parts of the board that are not flush against the wall), Tim Hortons Timbits and coffee (mandatory), power screwdriver, wall anchor screws, screw head holders/covers, pencil, whiteboard marker (to test the surface), utility knife, drill bits and miscellaneous bits/screws.

Putting it up:

At least two people are required to put it up but with three it makes it even easier. You’ll need about 30-40 minutes for each board. Basically level it, put some pilot holes into the board and wall, drive in the anchor screws, place the screw head cover holder in, drill the screws until the back opens up and tightens, finish it off with screw head covers. There you have it, “the simplest collaboration environment” (I recommend putting at least one in each office, you can never have too many whiteboards). They look like this:


@ the old office:





@ the new office:






Here’s a little more information on how to use your simplest collaboration environment from Mike Cohn: Instead of the typical index cards we use sticky post-its by 3M, not just the regular ones but the “Super Sticky” type (I think 3M made these especially for agile task boards). You don’t have to worry about tasks falling off the walls and getting lost. They actually work very well and you don’t need thumb tacks or magnets like with regular index cards.



That’s it!