Skip to main content

Relevance Points™ - Fixing the Issue With Agile Development

The Problem

When I have mentioned this to other people, most of them have been quick to agree: there's an issue with the way agile software development is done in many big corporations.

Often separate people fill the roles of a business person or developer. Then, a breakdown in collaboration occurs between the two. Particularly, many high performing developers are frustrated. They feel the business people make poor decisions impacting software development.

Consequently, developers lack the liberty to use their software development acumen to choose which software to develop, and how to develop it. Lacking this liberty, they feel pressured into developing software that they know will provide less value to the business.

The Solution

We propose solving this breakdown in collaboration by introducing a couple of easy metrics and roles: the Relevance Points metric, Relevance Spy role, Spy Stripes metric, and Double Spy role.

Solution - Relevance Points™

Developers might be frustrated that business people seem to make bad decisions affecting software. But, their ability to make good decisions is only as good as their information. How is a business person who does not understand software, supposed to assess the value of a software change? We believe Relevance Points may provide a way.

Each task could be assigned a number of Relevance Points, from 1-5.
By "task," we mean a unit of software development work. For example, a task could consist of a technical Jira ticket for a code change, a Git pull request, etc.
The Relevance Points would rate the software development work that went into implementing the task. This metric would signify the relevance of the task to the business problem. That is, the points would indicate how accurately the task did the right thing, and did the thing right.

Difference From Other Metrics:

The Scrum framework already provides for stories to have metrics including complexity points and priority order. Relevance Points are different. By adding Relevance Points to development tasks, we seek to provide a way for business people to assess the business value of underlying development work.
Additionally, Relevance Points could probably be applied equally well to various agile frameworks including Scrum, Kanban, etc.

Solution - Relevance Spies

Who could be qualified to appraise tasks for Relevance Points? Relevance Spies would be business people with adequate understanding of the underlying software. Perhaps some would come from a background in software development and end up working in more of a business role. The business could appoint one spy, to any project.
By "project," we mean a broader software development effort containing multiple tasks, and usually performed by a single, somewhat stable, development team.
The spies could draw on their allegiance to the business, and their understanding of the software, to appraise the Relevance Points for each task.

Solution - Spy Stripes

The Relevance Points would be misleading of the spy did not have a good understanding of software. Each Relevance Spy could be assigned a number of Spy Stripes, from 1-5. The stripes would indicate the accuracy of the spy's understanding of software development. A spy with more stripes would be considered more accurate in assessing Relevance Points.

Solution - Double Spies

The system would include checks and balances between the business people and developers. Double Spies would be developers with business acumen (possibly former business people who became developers). Developers could appoint one developer to be the double spy for any project. Double spies would be responsible to assess the stripes for relevance spies.

Possibly, the identities of relevance spies and double spies could be kept secret from each other to discourage ulterior motives.

Solution Summary

We feel that the Relevance Points would provide a way for non-developer decision makers to accurately assess the value of software development work. We think this would enable those decision makers to make better decisions in regards to the work. Business people would be able to recognize and reward software development that is truly better.

This could help liberate high performing developers to work on what they feel they should, in the way they feel the should--as long as it truly remains within the best interests of the business.

An MVP (Minimum Viable Product)

This system could be worked out with spreadsheets. Within one workbook, there could be a few worksheets, each with a few columns, in the following layout:
  1. Tasks
    1. Task ID
    2. Project ID
    3. Relevance Points - Number, 1-5
  2. Projects
    1. Project ID
    2. Relevance Spy ID
    3. Double Spy ID
  3. Relevance Spies
    1. Relevance Spy ID
    2. Spy Stripes - Number, 1-5

MVP - Integrating Such a Spreadsheet with Other Systems

The IDs within this spreadsheet would be arbitrary values for unique identification (for example, 1, 2, 3, etc.). Any information to relate these IDs to other systems, would be would be kept separately from this spreadsheet. For example, a Relevance Point Task ID from this spreadsheet could be added to a Jira ticket or Git pull request, tying those systems together.

MVP - Using the Spreadsheet

To apply the system to a new project, a project row would be inserted. The spies would be appointed as described, and IDs would be set in the project row accordingly.

Whenever a developer completed a code change task, a task row would be inserted. The relevance spy for the related project would appraise the relevance points. Then the double spy for the related project could re-apprise the relevance spy's stripes.

The business people could refer to the Spy Stripes to see when they needed to appoint a different spy to a project, to get accurate information. Then the business people could refer to the Relevance Points to get an accurate impression of the business value of each unit of work.

Please comment to share your ideas to improve this system.


Popular posts from this blog

Shared Project Manifesto Version 2

Contents: Introduction Launch Trade Reward Develop Vote Harvest 1. Introduction IP (Intellectual Property) is a great asset but it is hard to produce well. We hypothesize that a market to facilitate shared projects would make it easy to produce IP better. The Shared Project Model The market contains projects. Each project has one admin and a number of traders and developers. One user can have any combination of roles at the same time. For example, a user may be an admin and also a trader, or a trader and also a developer. Projects Users Admin:  Provides ideas in exchange for control Traders:  Provide incentives in exchange for growth Developers:  Provide IP in exchange for incentives 2. Launch When somebody came up with an idea for an IP product, they could create a project for it on the market. That person would be the admin. The market would record the time the admin launched the project. That lasting record could provide for the admin

Contact Codes Lite™

CCL (Contact Codes Lite™) would be a software product to help people exchange many kinds of contact information much more easily. CCL would do this by providing users with relatively simple contact codes . The users could distribute the codes to many people in many ways. Then, a person who received a contact code could use it to retrieve the original person's contact information through CCL. For example, many people still exchange business cards. Retrieving various information from the cards can be time consuming and error prone, especially when there are many cards. Also, when somebody updates their information, the information from the card is no longer valid. Other good examples for usage of contact codes include: On a slide in a presentation In email signatures On name tags In applications that provide limited space for profile information Whenever you want to provide easy access to many different contact options without listing each The main thing that would make


Directives go in, apps come out.™ An app to get software created without managing developers How it works: Go to AppDirective and become a CodeBoss™ Provide a simple description of your problem to  launch a directive Sit back and enjoy reviewing and approving contributions AppDirective uses advanced technology to get the software developed that you want, without you ever needing to hire a developer. Note: This app is currently about halfway built, at the time this is being posted. We plan to have it completed soon. Until then, please leave a comment or contact us  to become a boss. Q&A: Q: How do I get recognized for being original? A: When you launch a directive, you stake a claim to your app idea on a first-come, first-served basis. AppDirective™ keeps an unchanging public record that you deserve credit for claiming the idea at that time. Q: Does launching a directive protect my legal rights? A: No. Directives do not provide any legal protection

Please Comment

Have you ever heard of a similar idea? What challenges might an idea run into? How might you like to be involved? Comment to add your voice to each idea.