There is one memory I cherish from the early years of my career. It is a story of young leadership and wisdom shared by my boss. I wanted to share this to all fellow leaders.
A wicked problem
There was a system change that we had decided to execute in the near future. A new generation was to replace an old dated system. The old system was virtually without owner and most considered the system a black box. Just one introverted expert knew the inner workings of the system, and he did not share well.
The old system had countless dependencies to other disparate systems. Each system had it’s own owner. Everyone was afraid of touching the totality as the whole was clearly business critical. It was the system that performed subscription management and validation.
Who is going to tackle all of this. There was nobody. Except there was me who had time.
Asking around; making sense
I started going around the office and meeting the owners of the various systems. I had an A3 paper and a pencil. I kept updating the picture as I talked to people.
I would ask about the systems, their role, and their technical detail. What does the system do? What data does it store? How does it talk to the other systems? I listened and made notes. There was always a few mysteries and question marks on the drawing.
But bit by bit a picture emerged. A set of systems. Not so many eventually: maybe 5. There were connections that I could explain. I could explain how the system worked as a totality.
The wisdom of my boss
Remember I was a very young leader at that point. It was maybe my second year in any kind of leadership. What I did felt necessary and rational.
I don’t quite remember how I once started a conversation with my boss, but I wondered how come such knowledge didn’t exist in the company prior to my work. It was strange that we had been operating all that time just minding the daily business. I least I felt so.
My boss said to me:
Knowledge is power. Now you know how this set of systems works. You’ve become the expert and people will listen to you. They will trust your word. You can now affect things.
My boss implied people will follow me.
I’ve carried that notion of creating knowledge creating power ever since. Creating knowledge will give you power – you can create power for yourself.
PS: I seem to always get back to the necessity of doing the work. Doing the thinking. Putting the pen to the paper. Without that we will stay as is.
I’ve come to view development organisations and enterprises as networks of collaborating teams and value streams. A followup question to this is: “how does one steer a value stream network”?
This post has 3 parts. First a quick notion of a networked organisation, then a metaphor of pulling the network, and then the implications with suggested practise.
Maybe it is easier to start from the negation: a hierarchy of teams, programs, and units will not help create picture that matches reality. Such a clean organisation has no shared platforms nor any synergy between the branches of the organisation. That there would not be any collaboration or exchange of value laterally between the parts of the tree is not a reality. While the line organisation looks like a tree, the innovation spans across the branches. The branches collaborate on various levels.
A network of teams is a more apt metaphor for the development orgasnisation as it works with creating products and services people love. There are teams that create internal services, teams that use those, and ultimately teams that create touchpoints with customer or directly serve customers. When you draw the relationships of collaboration and value exchange you notice how it becomes a network.
Steering the value creation network – “Pulling from the side”
The development organisation as network, and seeing that as value exchanges allows us to visualise how to create goal-orientation and alignment. To get the second metaphor, you keep the network and the relationships. Now imagine the relationships are made of rubber band. And then you pull from the side of the network.
The green arrow represents the pull into the desired direction. We apply force and move the node into the desired direction. But that’s not the only node that needs to move, the whole network needs to readjust. This is where the notion of rubber band comes into play. The teams pull each other.
The pull cascades in the network, and then the other teams get pulled the same direction. The real life is not rubber band but collaboration, negotiation, and exchanging services. The pattern is clear however, all needed teams need to realign and move toward the objective. The pull cascades in the network.
Not everything cascades always through the network. Sometimes is a single team that needs to adjust. Some more complex things may need 4 teams to adjust. A strategic change will affect a majority of teams. The motion remains the same. The pull cascades in the network of teams.
The antipattern: cross-tension and too many pulling forces
The network pull serves as an illustration of the result of overburden and messy strategies. The orange arrows represent 3 additional goals for the network. If you think of pulling in all 4 directions at once, then you will notice the network will not yield cascading progress. The network will not move, but get rather it gets stressed. When you pull harder from all directions, the rubber band will eventually break. Again, this is something we can observe in organisations.
There’s clear similarity to situations of too many goals and incongruent goals. Same also happens when we try to achieve too many things at the same time. We overburden the network into a state that it cannot anymore flex. The nodes in the middle (platforms and shared services) get especially conflicted with pull from all direction. The goals with the least pull get starved for value exchange. The other nodes are moving away from them rather than collaborating.
Practitioner insights
The practitioner insights are starting from customer-facing value and then focusing decentralised alignment. I’ll elaborate on both.
Find the customer-facing edge of the network for optimal steering. We want to direct and pull the network into unique customer value. You will need to decide on positioning, strategy, and therefore direction. You use that direction as the pull of the network.
Then you will need to manage that the network accepts that direction. Team collaboration and the notion of the rubber band will work when you have well-connected teams and good collaboration ongoing. On top of that, you may need to consciously pre-empt and add more rubber bands.
The other short-cut to network alignment is broadcasting common direction. This is to share the knowledge of of the common pull immediately to the whole network. One however must have the collaboration and inter-team value exchange happening to actually move the whole network, and to create a new reality. One will eventually need the rubber bands.
OKRs is a popular strategy articulation and deployment method. It is particularly well suited to capture and put into action everything that I’ve written. It forces focus on global and team levels. It invites teams to sense the context and the network around them. The notion of “aligned OKRs” stresses that each team should have goals that support common objectives. The word aligned should be considered loosely and as a challenge to find the optimal directed tension across the whole network.
Nothing is perfect in human and networks. Our thoughts and plans never match reality exactly. Reality keeps changing and even the best plans are soon outdated. New opportunities appear as we make progress and build new baselines of service. Plans and network alignment need periodic update (realtime would be best :). OKRs achieve this with the selected cadence, where quarterly is most common.
OKRs work on the enterprise, organisation, and team levels. The work process of definition, alignment, and negotiation is the key. The OKRs are inherently a decentralised and concurrent process where the whole network is finding the right configuration and tension. That’s why OKRs should not be viewed as only a tree. Alignments will be cross-team, cross organisation boundary and skip organisation levels. There is no omniscient body on top of the enterprise that can see all of this. There is no tree-like divide and conquer with OKRs. It is about engaging the network in self-organisation. Self organisation in turn requires transparency, simple shared rules, and a common goal. OKRs is all of that.
Platforms come in many forms. They may be a software system such as the Salesforce which centralises the customer relationship management. All teams use the same system, and the sharing of data, activity visibility, and automation benefits all teams. A product line of cars may share a common car platform. This shares development cost and streamlines mass production. Multiple car products then benefit from this shared asset.
Having said the words shared asset we can immediately expand the definition into shared capabilities, shared processes, and almost anything that is shared across multiple teams.
The development value stream vs platforms
The value stream organisation is aligned with the set of operational value streams. Each development value stream has the mission to continuously improve the selected part of the operational value stream. For a classical ecommerce company, the total value stream is from marketing funnel to returns. One development value stream could for instance be “checkout & payments”.
We wish to tease out autonomous, long-lived, and fast development value streams. This however often is at odds with global optimisation. Take the CRM as an example: the customer data is needed in marketing, checkout, support, and returns.
The question becomes: if everyone is fully aligned with direct customer value creation and operational value stream improvement, who is owning and maintaining the platforms?
The business case for platforms
Roger L Martin proposes a fundamentally reverse way to look at the structure of the company. He proposes the thinking starts at the frontline where we meet the customer. The frontline is where customers choose what they buy, and our products fulfil their need. Sometimes a person meets the customer. For some companies the product is fully digital. Nonetheless, it all starts at the contact points with the customer. That is where we either win or lose the heart of the customer.
Behind the frontline, there exists a number centralised layers of the company. It could be the country organisation, it could be a department. It could be a business unit. It could be a team handling backoffice operations. Every layer behind the frontline must exist to make the frontline more efficient at fulfilling the customer need and to make the company more competitive.
It can generally be said that each layer behind the frontline must create more value than the cost of that organisational layer. The benefits to frontline efficiency is the only thing that can justify the platform.
Shared platforms make customer-facing development value streams more efficient
The role of platforms is to make customer-facing development more efficient. The primary measurement of efficiency in product development and agile is enabling speed. This can be achieved by reuse of solutions and by providing a semi-ready starting point for recurring things.
Platforms may also be used to achieve taming of complexity which would otherwise overwhelm single value streams.
Organising around platforms
The customer-facing development value stream has permanent staffing. We wish to promote longevity and continuous improvement. Similar approach is often needed for any non-trivial platform.
A platform value stream evolves the shared asset. Sometimes a single team is enough. Sometimes multiple teams are needed to evolve a complex platform. The mission is to improve the value delivery to customer. However, for shared platforms, the impact is indirect. The platform stream makes all the other streams more efficient.
Platform or customer-facing: it is not binary always
Some platforms may be owned by a customer-facing stream. Consider a case where the sales development team owns the CRM. The CRM then is leveraged by marketing and support to better work with customers. Then the sales development stream is both exhibiting customer-facing value creation as well as serving other teams with the platform.
A network of value streams
Once you start looking the whole enterprise starting from the frontline and frontline operations you now see a network of value streams. There are a number of customer-facing development streams. Those customer-facing streams interface with platform streams. As noted before development streams may offer some platforms as service to other teams.
When you start plotting the organisation as value streams that co-operate and interact, you will notice it is a network. (Hmm TODO: write about managing a value creation network 🙂 )
Epilogue: The lean wastes and platform handoff & Antipattern: selfish shared service teams
Lean manufacturing originally identified 7 wastes that you should work to eliminate. Among them are 2 relevant for platform teams: waiting and transport. Transport is the moving goods around in the factory. Waiting is waiting. When you hand off pieces of work from customer-facing development value stream to a platform steam, then you are incurring both these wastes.
In worst cases the platforms become inward-looking. The metrics of the stream are about own performance and own quality. The priorities come from within. Then there will be wait and frustration. Shared services become something that has to be forced upon customer-facing teams rather than being embraced by those teams.
An ongoing discussion in many organisations is around value streams. It is said value streams are the future organisational model. The benefits cited are continuity, focus, and simply to be able to divide the large company into pieces with minimal friction. Having said all of that, we notice achieving such benefits in an enterprise is not easy.
Many value stream starts never get started. There’s lots of discussion but little reorganisation. My pet peeve there is that a glaring lack of common language around the subject. Projects, workgroups, temporary teams, teams of teams, and many other are called streams or value streams.
To present my perspective and my model, this post series has the following parts
Formal definition of a value stream
Splitting the enterprise into parts using the value streams as guide
Tried and true ways at arriving at value streams (todo)
Platforms and value streams (todo)
Evaluating your current condition (todo)
Value stream defined
Value stream and value stream thinking stem from the Lean movement. In classical terms:
A value stream is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer
pulled from the internet
The key takeaways there are 1) customer and value being in the center and 2) the end-to-end nature of the value stream. That it combines everything needed to go from need to value.
Value streams are semi-permanent. They do evolve over time as customer needs and preferences change. Also, the enterprise’s way of meeting the need evolves over time. Now and then there’s a revolution, but the value stream is still relatively stable over time. This is good as this stability forms a basis for continued learning and incremental improvement.
To apply this in product development context we need another definition. A product has a multitude of definitions but Lean Product leader Meliissa Perri’s definition will serve our thinking the best here.
A product is a vehicle of value
Melissa perri
That is: a product is the vehicle of recurring value. It can be replicated. It can be scaled. It is the one that meets the customer need and creates the customer value. Sometimes it is a physical thing. Sometimes it is an automatic service. Sometimes a person does the job. Often the product is mixture of all that In product development we improve the product.
The satisfaction of the customer need is the aim. The product is the vehicle that both produces the value and delivers it to customers. And the development improves the vehicle in a continuous fashion.
Therefore & from now on we call the set of activities to meet customer value the operational value stream. Then we introduce a new term: “development value stream”. Development value stream is the recurring set of activities to go from an idea to improvement of the product. Both of the value streams are long-lived.
Splitting the enterprise into parts using the value streams as guide
The definitions by now – the operational and development – value streams carry a practical problem that the development value stream is monolithic and big. An enterprise usually has multiple products, but still the development value streams would be big and monolithic. You will want to divide this elephant for focus while maintaining continuity.
I like to use an example of a bank. An operational value stream in a bank might be called the “home journey”. That starts when the customer starts to dream about buying a new house. The operational value stream ends when the house is financed and bought. One might argue that the value creation continues until the debt has been paid off, but you will notice how the activities in consumer lending go from need to value.
The purpose and mandate of the development value stream for home journey can now be discussed. It likely could be connected with customer satisfaction or the timeliness of the process. You have a choice of metrics related good customer outcomes as well as business outcomes such as increased lending or better rates. The team immediately has a long-term purpose, directly tied business-critical outcomes.
You will end up with rather large value stream still by connecting the development value stream “one-to-one” with the operational value streams in the enterprise. A more fine-grained approach is to create development value stream to relevant subsets of the operational value stream.
To arrive at more fine-grained development value streams, you can look for relevant activity sets in the overall operational value stream. Consider the classical e-store value stream. It is roughly something along the lines of 1) marketing and demand generation -> 2) customer browsing the store 3) choosing the right delivery option -> 4) payment -> 5) delivery & tracking -> 6) returns. In addition we notice there’s a separate value stream for 7) support.
Having expanded the operational value streams, we notice that often we are already teamed up like this – e.g. there’s a team or a few working on payments. With the value stream viewpoint we can now be mindful of the organisation and start to manage consciously.
Form development value streams for subsets of the operational value stream, according to mid+long-term strategic agenda.
Antti Tevanlinna
Now we have a formal model for picking the development value streams based on products and operational value streams. This is a good start to have a conversation with common terms.
A bit TODO
There’s 3 followup posts / paragraphs that need writing to convey the overall story. They include the “how” of finding value stream, the guidance on internal platforms in relation to value streams, as well as “how to know whether you are doing good or bad”. Without this underlying understanding it is hard to choose between different configurations – and you will always find multiple configurations when you start looking for value streams.
Rather than doing a wide and shallow analysis across everything, formulate prototypical choices and analyse deep
Paraphasing Roger L Martin, one of leading strategy practitioners
There are 2 hairy problems in tackling strategy formulation in large corporations. I call the problems 1) too much to understand and 2) too many possibilities. These problems arise from scale of the company and the human nature of the problem. Also, the longer time horizon of the analysis adds to the problem. Let’s look at the problems in turn. Then I’ll advocate for splitting the elephant as a way to overcome these.
We want the corporate strategy to cover all of the company, to guide everything, and to make everything great in the future. Intuitively this is a worthy goal. Framing that as optimization problem however leads to an immense task. One needs to analyse current and future customers, predict market dynamics, take into account technology trends, anticipate competitor moves, and design for internal capabilities.
Taking a standard 3-5 year planning horizon, the amount of analysis is huge. We only need to start to detail down the tasks of each mentioned area of analysis and notice how these all require man-months analysis to come to an understanding. But as the assumed goal of strategy is global optimisation, then the parts need to fit together. The “design” becomes vast and over-reaching in detail.
When the analysis and optimisation problem is “everything” in all possible future events, then the detail will overwhelm each and every team taking on strategy formulation. Based on experience this starts to happen already in as small companies as 20 staff. There are simply too many customers, too many services, too many attributes, too many processes. You go down the rabbit holes.
The “too much to understand” problem is both a problem of strategy formulators time usage as well as cognition.
The second problem of “too many possibilites” stems from the same underlying forces. The domain of analysis is wide and rich. This means one keeps coming up with practical ideas of how current problems might be solved. This leads to endless combinations of attributes, positions, capabilities, markets, trends, and products that might be included in the strategy being formulated.
This problem is usually compounded with the lack of common vocabulary and structure of analysis. Looking ahead and wanting to generate good solutions is also very human. People keep wanting to help and chip in. The problem is that you end up with tens of claims of “what the strategy might be”.
Making sense out of the possibilities is then hampered by the lack of “knowledge” of the overall problem. That is we come back to the first problem. You cannot evaluate the validity or the merit of the suggestions easily. For that reason, many do not wish to discard good ideas.
Now in the story, you – the strategy formulator – are left with 1) insufficient knowledge of whole of the company and the future market and 2) with many possibilities of “what might be a good solution”. In the words of Roger L Martin: you’ve done shallow analysis of a very wide set of topics.
You have many possibilities that might work. You are not certain of any of the possibilities.
You therefore cannot deem where to go next.
The antithesis – Narrow and deep analysis
The antithesis to wide and shallow analysis is narrow and deep. This is how it works.
Do quick analysis of the environment to gain introductory knowledge of the domain
Generate a list of plausible strategies – use for instance playing to win or blue ocean strategy to create a set of strategic prototypes. Focus on the core characteristics of competitive advantage: differentiation, position, and – in the case of larger corporations – scalability
Prioritise for “going deep”
Analyse each option “in depth” trying to de-risk and to find the best known arrangement for “strategy-market-fit” (think product-market fit, but for a strategy)
Maybe this is then another post, on how to go deep per strategic prototype.
The set-based approach to strategy formulation
Taking the narrow and deep approach will produce more thoughtful and lively strategies. They are much more in alignment with the market and realities of the company. However, a problem with breadth and coverage of the whole company will remain.
You can scale the narrow and deep with set-based approaches. Multiple teams can work concurrently on different option and strategic prototypes. This both allows for more people to practically join the process as well as giving us more possibilities of finding a gem of a strategy.
Finally, we come to the difficulty of deciding when is a strategic idea “validated and de-risked enough” that we dare to put the whole company behind it. Having framed it like this, I suppose few large companies will want to the eggs into one basket. Only when strategic ideas have gained real market traction, will there be significant investment. This in turn means that it is actually good to nurture a set of possible strategies with small investment and try them out in small scale.
Take it this way: what is the most effective way to search for a great and punchy strategy? Once you frame it like that, I suppose you don’t want to go back to wide analysis. For a search problem, you want to move fast, be specific, and keep testing your idea.
Start small, think big. Don’t worry about too many things at once. Take a handful of simple things to begin with, and then progress to more complex ones. Think about not just tomorrow, but the future. Put a ding in the universe.
Steve jobs
Agile sometimes feels directionless. Strategy sometimes feels overwhelming, vast and nebulous. It is sometimes like oil and water that does not mix. You need a practical way to start small while thinking big to make the connection.
The key to making a connection from strategy to acting small and agile is being precise about your assumptions and unknowns. The assumptions and unknowns exists in all strategies. The magic starts to appear as you start approaching strategy formulation as an explorative journey. Then you can “act” and iterate over the parts.
Before we go into the process, I feel I need to give a definition of “what is strategy”, especially in business. In this process refer to strategy as 1) desired future state of company, customers, markets 2) company’s unique position and competitive advantage over competitors (via differentiation or low cost), and 3) the mechanics and the business model (activities, capabilities, systems) that form the unique position. The 1 and 2 are the “what” of the strategy. The 3 is the “how”.
My personal preferred strategy description model is the “playing to win” model. There are 5 levels that – when interconnected and with unique choices – form a coherent picture of the competitive advantage. Those levels are 1) What’s the winning aspiration 2) Where do we play? 3) How do we win? 4) What activities are needed to win? 5) Management systems that keep us on track
Competitive strategy is about being the best in what you choose to do. To be better, you have to be different. Nobody can be worlds best at everything, so you have to make choices. Since differentiated strategy is about being different, it is also a sidestep from industry norm and current common practise. Being the best will require inventing new novel ways to outperform the benchmark group.
This innovation and stepping out the of the norm introduces the strategy process with complexity, human element, and uncertainty of success. In the words of Richard P Rumelt: Strategy creation is about being on the edge of our knowledge and stepping beyond. I personally do not think novel choices appear from lengthy analysis only. A dose of creativity will be required. That spark that forms into clarity by rounds of refinement.
The Agile movement has embraced open-ended problems. We start small, create something, seek feedback and learn. We grow solutions piece-by-piece. Can we connect this iteration to strategy formulation?
Risks and unkowns is the glue between strategy formulation and agile. If we can tease our the risks in a strategy, then we can divide and conquer in an agile fashion.
The playing to win is accompanied with a formulation process. The process is iterative and follows the steps
Step 1: Form a hypothesis of your competitive position by drafting answers to the 5 levels. Make choises that just *might* win.
Step 2: Use the trigger question “what would have to be true for this to be a great strategy”. This teases out underlying assumptions that have gone into the the thinking. Answering this question broadly will yield implications about the future markets, customer preferences, capabilities to be developed, and barriers to entry.
Steps from 3 onwards: Validate the assumptions in priority order. Analyse markets, build prototypes, make quick experiments to see if your strategy is valid. If the assumptions don’t hold (and many should not), make alterations to the strategic choices.
In agile terms, you make a backlog out of the assumptions (call them risks if you like), prioritise them, and tackle them as fast as possible. The whole process is outlined by Roger L Martin in the excellent blog post https://rogermartin.medium.com/strategy-design-thinking-faf6b787160b .
Tests come in many forms. Questions about markets can be answered by classical analysis. Risks related to technology can be explored with prototypes. Customer desirability can be measured with experiments. We take conscious, targeted actions that prove we are on the right track. When we pay close attention to results, we often notice our original assumptions were not quite right. Then it is time to change the choices.
First versions of the implementation of the strategy
I’d like to see the strategy going from idea to being tested to “strategy-market-fit” 🙂 Wink wink to all product thinkers and experimenters. This time we are not doing a new product or value proposition. We are now iterating to a great strategy.
—–
Note to self: write about teasing out assumptions and prioritising them.
I often bump into a trouble in prioritisation, when people are combining the value of a story and the size of a story into the same discussion. The discussion become hard and decisions become muddled. The other problem is that people find it hard to get started with comparing the value of two stories.
I’ve recently taken into use a simple question that most of the time does the trick. The question is
Let’s suppose a good fairy-mother comes and says: I’ll give you a wish. I’ll give you one of these two absolutely free. Which one will you choose?
This takes the whole cost/complexity/time out of the discussion. It somehow (magically) makes the choice intuitively simple for most.
So, just give it a go. It only takes 10 seconds to try out 🙂
work expands to fill the time available for its completion
A proverb coined by the twentieth-century Britishscholar C. Northcote Parkinson, known as Parkinson’s Law. It points out that people usually take all the time allotted (and frequently more) to accomplish any task.
I’ve met passionate argumentation both for and against the validity of this “law”. Odd isn’t it? That’s because people interpret the world based on what they see.
Those who believe in the law actually experience this phenomenon all the time. Tasks don’t get done if there’s no deadline.
Those who believe the law is just wrong usually prioritise and strive for getting the most important bits done as early as possible. They view deadlines as counter-productive.
The most common underlying difference in the worlds these people live in is the amount of work-in-progress and open tasks. The people in the organisations that are overburdened with too much work are always in a situation that they need to trade off which tasks get done and which ones get sacrificed. A natural way to select what to do is to look at the upcoming deadlines. One tries to optimise to finish as many things as possible before the deadline arrives.
Therefore finding belief in the Parkinson’s law has now become an indicator for me that the organisation is overburdened.
A related “law” is what I’d call the “responsibility law”. It pretty much goes that: If there’s nobody responsible for an action, then the action will not get done. The mechanics is very similar. People choose tasks based on personal view – often according to deadlines. They try to make the best in a losing situation of having to be late with some (personal) tasks. This leads to starvation of effort on the tasks which are “not in personal possession”.
A colleague of mine added the following insight
The idea that there needs to exist a continuous pressure and that there needs to be more to do, so that we can ensure that peoples’ time is used efficiently.
This to me is very much related to the idea that we want to control the time usage of people.
Nitor has a great culture where all employees take initiative way beyond normal expectation. Some volunteer to plan new wonderful office space. One is a superb party planner. People take initiative, and they swarm around ideas and needs. It just happens without poking or forcing.
We’re now 10 years old and we total more than 100 people. We’ve only a few designated roles. There’s two companies in the group and two CEOs, who are the bosses of everyone. The people ops keep the office and money running. We’ve two guys focusing on hiring. And we have two part time senior party architects.
The company was founded by 6 founders who are still around – doing stuff. You probably might not notice who they are before you are told or you get curious. And that’s all there is.
There are DevDays, clubs, and all kinds of stuff happening all the time. So where does all stem from? I’ve come to conclude there’s two factors.
Firstly: there’s no management to give orders to people. The only direct order I’ve heard is to “clean up” the office a bit better. Beyond that, there’s just no orders. Zero.
Secondly: We make things visible, available, and simple. We give thanks to those who contribute on the company level. Sometimes it feels weird how much kudos there’s flying around. Even things that might feel ever so small get noticed. But the thank-you is what is keeping the people moving.
100+ people, no orders, and thanks. That’s one way to empower the smartest people you can hire. We have proven that.
It took me 1.5 hours to get this working on a fresh Jira Cloud evaluation version. On-premise Jira has a different set of plugins, so a slightly different path is needed. It however is quite simple to get this running – provided you can bribe your Jira admin to install a new plugin 🙂
This is how it works
In the listing
This all was done with the Abacus plugin that allows you to do math based on values “fields”. All of the above is automatically calculated by the Abacus plugin. Any time you change any of the WSJF components, then the calculation is redone automatically.
The summing of Business Value, Risk Reduction/Opportunity Enablement and Time Criticality was the first calculated as the “Calculated total value” column. The WSJF result had also division by job size/duration included.
Pricing of the plugin was IMO bearable. If you need similar with on-premise Jira, then look at JIRA Misc Custom Fields.
So that’s short and sweet, hope this gets you started.
Then I spent a bit more time to visualise this. As usual, to get something you need in Jira, a plugin was again needed. This time it was the easyBI plugin, and that gave me a nice bubble chart of how the items relate to value vs size.
anttitevanlinna's blog 