Skip to main content

Optimize your resources- Apply the 80-20 Rule

Formally known as the Pareto principle, the 80-20 rule states that "80% of the consequences stem from 20% of the causes."

Startups - who by definition are starved for resources - would do well to apply the Pareto principle to everything they do.

From Wikipedia:
  • It is a common rule of thumb in business; e.g., "80% of your sales come from 20% of your clients."
  • It also applies to a variety of more mundane matters: we wear our 20% most favoured clothes about 80% of the time, we spend 80% of the time with 20% of our acquaintances etc.
  • In business, dramatic improvements can often be achieved by identifying the 20% of customers, activities, products or processes that account for the 80% of contribution to profit and maximising the attention applied to them.
  • The idea has rule-of-thumb application in many places, but it is commonly misused. For example, it is a misuse to state that a solution to a problem "fits the 80-20 rule" just because it fits 80% of the cases; it must be implied that this solution requires only 20% of the resources needed to solve all cases.
This is exactly what Agile development is all about - 

identifying and focusing on 20% of the work that gives you 80% of the value!

Comments

Popular posts from this blog

Splitting User Stories vs. Rally's "split" feature (that has nothing to do with it!)

Agile tool Rally has a "split" feature it recommends to handle "unfinished work" in a Scrum Sprint: Manage Unfinished Work - Split user stories ( new link ) Below are my observations on the "Split" feature in Rally (followed by a few excellent articles on Splitting User Stories):   This "split" feature in Rally has numerous problems: 1. Nothing to do with Splitting User Stories It has nothing to do with "Splitting a User Story" which is an advanced but fairly well-understood field in Agile, and a tool for Product Managers to use in one of the two scenarios: The Product Manager does it before an Iteration commences (i.e. during backlog creation or release planning) to create User Stories by business value that are right-sized, i.e. they can be comfortably implemented inside an iteration; The Product Manager does it in Iteration Planning or in the middle of an Iteration to reduce scope by removing/simplifying accept

Agile Entrepreneurs Manifesto

The  Agile Manifesto  defines the 4 core Values that define "Agile":  " Individuals and interactions",  " Working software",  " Customer collaboration", and  " Responding to change" As I applied Agile requirements (user stories), engineering (XP), and process & project management (Scrum & Kanban) to my startups  (RideStation, and Agile Entrepreneurs)  starting from 2005 to now in 2018, I learned numerous lessons and shared them with my fellow entrepreneurs for the next dozen years. These lessons I have incorporated by "extending" the Agile Manifesto with two additional values pertaining to  Product (5th) and Startup/Business (6th)  -  that the services consultants who wrote it in 2001 probably didn't have to contend with as most (all?) of them were not founders of product startups:  "User Validation, Customer Traction, and Business Milestones" Agile Entrepreneurs Manifesto Us

User Stories: you're not Agile without them

Failure to effectively transition to Agile development is often based on a fundamental failure to understand what a User Story is. Allow me to explain. The most important aspect of a User Story is that it's an independently *schedulable* unit of requirement (feature). The key to achieving the "independently schedulable" characteristic of a user story is that you express it in terms of how a "user" would use it. This leads you to a unit of functionality that's implemented end-to-end (UI to backend) that a user can actually interact with. Not surprisingly, because of the focus on how a user would think about a feature, a user stories are highly readable - and could very well be written by the users themselves. However, the other important and less obvious aspect of a User Story is the emphasis on communication with the end-user and getting confirmation on the acceptance criteria. Describing all the requirements as User Stories for a decent sized product is