Scrum 101: The 80/20 Rule

The principle of the 80/20 rule is 80% of the whole, or value, comes from 20% of the execution. Also known as the “Pareto Principle,” this rule is intentionally vague because, as discussed by Kevin Kruse in Forbes, it’s found everywhere. From an execution and product standpoint, Scrum applications of the 80/20 rule vary. The rule could mean a minority of the development team will interact with the majority of your tasks. The rule could also imply that a small subset of your bugs will interfere with users the most. Like laws of nature, these elements occur naturally, but the true value of the 80/20 rule is when you actively exploit it to improve your overall Scrum developing & delivery process.

The 20

Scrum is aligned to exploit the Pareto Principle. The time constraints of a sprint paired with the pressure to produce a high-functioning product can be daunting. Sometimes, these constraints lead to engineers building around requirements instead of developing a solution. Then, post-review, the developers can make their case for further enhancements for the next sprint. This candid conversation fosters an environment of simplicity and team efficiency.

Now the developers and the project can stay on track for delivering not just a product, but the value to the client. The Scrum process empowers the team to keep building the 20% that matters and to cast a critical eye towards scope creep. This attitude is not easy. As we know, many developers feel like the task’s not finished until it can cook itself dinner (wouldn’t that be great?). By setting good task definitions, the value-based solution development can be achieved!

The 80

Kinney Group strives to connect our work directly with our stakeholder’s needs and objectives. We developed “The 3 ROIs Framework” to make that happen. Through the framework, our Kinney team outlines the financial, human, and business objectives of our customers on every project we deliver. The 3 ROIs Framework is further enhanced by Scrum teams that fully exploit the 80% value to deliver the unexpected experience to our clients.

By nurturing an environment for candid feedback between developers, product owners, and users, the team can identify key features that are punching above their weight. These are your “special treatment” features. These features may take additional interface work or enhancements towards improvement. Although they may seem small, these features can improve first impressions towards the overall product. This precision can turn your application from a jack of all trades to an instrumental piece of software, strengthening your client’s mission, financial, and human goals.

Again, this laser focus is at odds with developer behavior behind building the complete picture, requiring user feedback. It is important for product owners to take on the role of championing the users’ needs and equally important for the development team to listen.

The Takeaways

Of course, the 20% of this post that provides 80% of the value is the wrap-up summary. Take these tips and help shape your Scrum and project delivery processes:

  • Re-enforce iterative development. This will ensure each sprint is forcing developers to take the short, simplest routes. Then, they can re-assess in the next sprint if additional work is actually needed.
  • Have candid conversations with your Product Owner and users. These folks will lead you to find the 20% of your product that provides 80% of value.
  • Prioritize work that aligns with the 20% features. You want your solution to shine for users. Always have a bias to improving this feature over adding additional bells and whistles.
  • Gather your ROIs from your client and start by discussing the 80/20 features.

At Kinney Group we design, build, and integrate IT infrastructure solutions for some of the most demanding government agencies and commercial organizations in the country. As an organization, we develop our solutions through Scrum and agile best practices and delivery. By leveraging next-generation technologies, adopting proven engineering practices, and agile development principles, we create custom solutions and world-class environments for data.

Want more information on how we can put that power to work for you?

Scrum 101: Three Myths of Traditional Scrum

Hi, I’m Georges, Scrum Master Myth Buster.

As a resident Scrum Master at Kinney Group, I’m responsible for promoting and championing Agile & Scrum habits on our automation projects. I started off as a developer, which shaped a lot of my goals and expectations in Scrum today. I have a bias to producing work, lightweight management involvement, and simplifying everything that’s not technical. A Scrum Master’s role is to produce an environment that is encouraging for developers and for growing the Agile mindset. Throughout my journey of training, execution, and experimentation, I have seen common Scrum myths permeate through the software development and project management ecosystem. Follow along as I debunk three myths about traditional Scrum best practice, so hold on to your Jira tickets and let’s go through the big offenders!

Myth #1

Scrum makes my development teams more efficient.

One of the first books I read for training was “Scrum: The Art of Doing Twice the Work in Half the Time.”A great read for learning the Scrum trade, but with an untrained Scrum eye, some directors and management may take away the wrong impression of how their teams will operate under a new delivery framework.

Teams today are most likely doing a hybrid practice of Homebrew/Waterfall/Agile systems. A distinct change in your Agile practice may reinforce good habits that make your team faster, however, it’s important to remember that speed is not the goal of Scrum. The goal of Scrum is to make our teams more effective not efficient.

With a bias to client and user interactions, our engineers are executing on project goals while verifying their work repeatably. Many may argue that effectiveness leads to efficiency from a high level, and they would be right, but the message behind Scrum-based development should never promise the moon. Short-term stumbles and smaller gains will happen along the way and Scrum allows your team to break these bad habits along the way. Sometimes, a team needs to slow down before they can speed up, resulting in more effective work to reach a customer’s goal.

Myth #2

Scrum is a set of meetings and rules for my developers.

I love this myth. It’s at the same time entirely true and completely misleading. By reducing Scrum to its artifacts and ceremonies, we ignore the foundation that Scrum rests upon — the Agile Mindset. When you ignore the Agile Mindset, your Scrum practices will never reach their full potential. This may ultimately get in your way instead of fostering a better development environment.

Equally important, the Agile Mindset not only requires your developers’ participation, but it involves your entire delivery pipeline. Your company’s salespeople need to champion the need for Product Owner involvement. Your business analysts need to write Statements of Work that promote handshake agreements on changing priorities. Your project managers need to keep their development teams as stable as possible. Scrum is not a set of meetings and rules for your engineers to follow. It’s a shift in the entire delivery framework and requires everyone to pitch in.

Myth #3

Scrum is the evolution of Waterfall and supersedes it.

Scrum and Waterfall are two delivery frameworks eternally locked in a misguided war of buzzwords and superstition. The truth is, they both have value for different reasons. Scrum did not kill Waterfall. However, Scrum did create a system that is better suited for rapid development, experimentation, and unknowns. Waterfall still has place for fixed, ‘simple’ work requirements. By requirement and by design, these won’t deviate from the initial technical and feature scope. With complex, initial asks on a Waterfall project, it’s no wonder that Agile processes have taken over. However, it is important for developers and managers to treat the words, “We are doing Scrum” with respect and not as a not-so-clever way of saying, “We aren’t doing Waterfall.”

Myths = Busted

There is a common misunderstanding intertwined within these myths: Scrum is easy. The truth is that Scrum isn’t just a simple evolution of the classic plan to execution flow of Waterfall. Scrum requires all hands-on deck in an organization to support. It is not a band-aid, but a methodical shift in how a company operates. If executed and supported sufficiently, adopting a Scrum practice can result in the effective delivery of your product and, most importantly, happy clients.