How to be predictable without estimation

Estimating knowledge work (e.g. software development) has always been a big challenge. Developers and team leaders try to help managers and clients to predict budgets, prioritise, and meet the goals by estimating the amount of time, money, and effort of the work. 

At least that is the theory behind the estimation, however, in reality when the problem is complex with high uncertainty then the estimation won’t be straightforward and accurate. 

In this article, I’m going to explain how we can be predictable without estimation. But first, we need to understand how to generate and read the Lead Time Distribution chart (AKA Histogram).

Let’s have a look at the following Lead Time Distribution chart, which represents all the works that one of my teams delivered, in the last four months.

X-axis: shows the number of days from when the work is committed until it’s delivered to the customer (Lead Time). Please notice that this is a range and not a single number. For example, the value of 10 shows all the works that took between 5 to 10 days to be delivered.

Y-axis: shows the number of works that fit into each range. For example, if you look at the first bar, you’ll see that 25 works took less or equal to 1 day or 65 works delivered between 1 to 5 days.

Now let’s dig into it with a little bit more details and see how we can read the chart. As highlighted on the chart, 70% of works are delivered within 10 days. If the service level expectation is 10 days then this means 30% of our customers’ requests were delayed. 

Lead Time rangeNumber of works delivered
0 – 5 days37%
0 – 10 days70%
0 – 15 days86%
0 – 20 days96%

How we can predict when a new work will be delivered to the customer? 

We look at this team histogram and based on what actually happened in the past we predict the future, and this is because what happened before, will most likely happen again. 

When a new request to the team, we can predict that if we start it today, there is a 70% chance that it will be done within 10 days. If this is not acceptable then we should start it 15 days before the expected delivery date which gives us an 86% chance that delivers at the right time. Sometimes there is a fixed due date and the request MUST be fulfilled on or before that date, in this case, we should start 20 days before then with 96% accuracy the job will be done at the right time.   

Now we can predict when the job will be done without estimation!! And we can spend our time on something more valuable. 

Histogram with long tail

Sometimes your histogram (Lead Time Distribution chart) has a long tail. Please look at the following chart.

As you can notice in the second chart, there are some works that took a lot longer and caused a long tail.

Long-tail means low predictability

 In the following table, I’ve compared the predictability of both teams and you can see that the team with a long tail has much lower predictability. If Team A (no long tail) wants to have +95% accuracy of the delivery date, then they should start 20 days before, which is 60 days for Team B with the long tail.    

Lead Time rangeNumber of works delivered (Team with NO long tail)Number of works delivered (Team with long tail)
0 – 5 days37%31%
0  – 10 days70%52%
0 – 15 days86%64%
0 – 20 days96%71%
0 – 60 days100%98%

Conclusion 

Estimating the size of the knowledge works have been always challenging and had a negative impact on customers trust, people moral (blame game) as well as low-quality products. By measuring the Lead Time and how it’s distributed historically we would be able to be more predictable while we are predictable, in fact, we will be more predictable and this is because we predict based on what actually happened in the past rather than guess. In Team Kanban Practitioner and Kanban System Design courses, we will discuss the Lead Time Distribution and explain how this chart can help us to improve the system.

Orod

Orod is an Agile Coach, public speaker and Accredited Kanban Trainer, SAFe Program consultant, Scrum Master and food vlogger.

Since 2010, Orod has trained and helped many organisations in a variety of industries, to design sustainable kanban systems and support them to gradually improve their business agility by delivering the right work at the right time, without changing job titles or oranisation structure.

The Six Trumps

I was on a training session a while ago and found myself doodling, by the way this is normal for me as I like to take notes and pictures as it is part of my learning style, I was paying attention…honest!

The course content was reflecting on the concept of DIMWiTS to articulate The 6 Trumps which are six brain-science principles that ‘trump’ traditional teaching and training techniques. This is how I captured the concepts. I have this on my wall as an inspiration during training, right next to The Four C’s.

Here are some examples of how I have chosen to apply these concepts in my training delivery:

D
Different Trumps Same – Mix up or mash up the training session with different types of tools and activities using a combination of Mural, Miro, slides, whiteboard physical and virtual, flip charts (yes even in virtual classes), objects around the home to create personal connections, workflow tools for practical scenarios like Jira to show how to do it in the real world, Lego, music, toys, games, competitions, hats, student workbooks so learners can write and draw along with the content.

I
Images Trump Words – Try not to go heavy text on any training content. Rather use pictures or photos on slides that represent the context and have the 2 way conversation with the learners. Tell stories and listen to stories about the content that takes the cohort on a relatable journey. Have learners draw their own images of their relatable story and play it back to the group.

M
Movement Trumps Sitting – Everyone training session needs regular breaks, these need to be even more regular in virtual training. Outside of lunch etc. take a break every hour, up to 10mins. We sometimes use ‘ticket ins’ and ‘tickets out’ to have learners do something before they leave or do something when they get back. Before they leave provide a conclusion of what was just learned or during a break have them go find something in their house that they are proud of to share when they come back.

Wi
Writing Trumps Reading – Most of our training sessions involve creating an improvements plan for when you go back to you job. Real improvements you can measure. So during some class activities teams break out into pairs or small groups to generate ideas and concepts that they present back to the main group, sometimes its personal and learners will create their own graphic organisers of pictures and text as they work through the course material.

T
Talking Trumps Listening – Depending on the activity learners will pair off group in small teams. They need to discuss the content & concepts to form their own conclusions, mash other trumps in these activities. Liberating Structures are very cool examples of how to mash up activities to lead to the desired conclusions and get everyone involved. Key here is providing the guardrails so the activity is clear enough not to get side tracked with the ‘rules of the game’.

S
Shorter Trumps Longer – We tend to break large batches of learning concepts into smaller segments. So rather than completing the section in its entirety we will make sure that each concept segment delivers a learning objective and is still valuable concrete practices. We pull those segments back together as a conclusion covering links to the overall learning objective.

Credit to Sharon L Bowman, check out more of her work at bowpearson.com

Jas

I love agile, I mean I really love agile!

It has provided me with so many fantastic opportunities and experiences that I cannot help but want to share its awesomeness with others and provide them with an avenue to grow as well.

That is why, as an agile coach and trainer, #ilovewhatido!

I am on a mission to demystify agile at scale and help organisations and individuals connect with their inner awesome to meet complex challenges head-on.

The difference between Work Item Type and Classes of Service in Kanban

One of the first challenges for those who are new to Kanban is to differentiate between Work Item Type and Classes of Service (CoS).

First, we need to step back and see why we need these concepts in the first place. In Kanban, everything is organised around the customer and a service delivery team that focus to fulfil the customer’s request. 

The customer always has a request and accepts it when it’s fulfilled by Service Delivery Team.

Work Item Type is what the customer wants.

Classes of Service is how Service Delivery responds to customer’s needs (or Work Item Type) to ensure the most valuable work is delivered to the right customer at the right time and reduce the cost of delay.

Example

To clarify let’s assume that there is an application, which recently has gone live and there is a team, which is responsible to maintain and improve this application. Imagine this team has 3 customers explained below:

  • Customer service; who needs stability and expect bugs and production issues resolved within 12 days.
  • Sales; who needs new functionalities to compete with other competitors and stay in the market. They are the main revenue line of this company. They can wait for a longer period to see something happens, however, due to the demo to the client and some key milestones some of their requests must meet the deadline. 
  • Engineering manager; who is looking after security and platform improvement. His requests are mostly not too urgent, however, sometimes there is a hard deadline due to license expiry and other issues.

According to the above example, there are 3 Work Item Types raised by customers and now Service Delivery Team needs to prioritise them so they have the following policies which help them to prioritise customer requests.

Classes of ServicePolicies
Expedite– This request can’t wait
– Drop everything and focus on this one
– Release when it’s ready (on demand)
Fixed Date– This request MUST meet the deadline
– This request can wait
– Might be released on demand
Standard– This request can wait
– Pull and start when capacity available
– Release based on release cycle
– FIFO 

As you noticed, Service Delivery maps Work Items to Classes of Service to be able to prioritise the requests to satisfy the customer.

Here is their work distribution histogram and below explained what that means:

Average Lead Time
1085% of their works completed within 10 days Lead Time
1592% of their works completed within 15 days Lead Time
2099.2% of their works completed within 15 days Lead Time

That helps team to prioritise and also have a good service level agreement with the customer. For example, in the above example, the team knows that if they pull the work today, there is 85% chance that it will be completed and delivered to the customer in 10 days, if 85% is not acceptable and 90% is, then pull it 15 days in advance 

Conclusion

Work Item Types and Classes of Service are two completely different concepts, Work Item Types represent customer needs and Classes of Service represent how the deliver team wants to treat customer request, to deliver the right work at the right time. 

Orod

Orod is an Agile Coach, public speaker and Accredited Kanban Trainer, SAFe Program consultant, Scrum Master and food vlogger.

Since 2010, Orod has trained and helped many organisations in a variety of industries, to design sustainable kanban systems and support them to gradually improve their business agility by delivering the right work at the right time, without changing job titles or oranisation structure.

Is method bashing the new inquisition.

I have pondered for some time my thoughts and feelings on method or framework bashing.

On one hand everyone is entitled to an opinion and we should show openness to other points of view.

However, in some cases, how these opinions are delivered can be considered borderline bullying and disrespectful.

I have been a student of agile for many years and still consider myself on a learning journey. On my personal agile pilgrimage I have explored a wide range of agile concepts, practices, methods and frameworks. I have found some that I naturally resonate with, by that I mean they work well for me as a human. When I walk into a new situation to apply my skills and knowledge, client or employer, I pull on this experience and know that the environment that I have stepped into has its own needs, preferences and culture. Indeed if they have already implemented new ways of working, their agile might not be my agile.

So why are there so many individuals that say things like:

  • “Framework X is not agile”
  • “If you do X you are not agile”
  • “You cant use the word X to describe your agile courses”

If we all agree what we do in an agile world is base our patterns around the agile manifesto values and principles, then we are all part of the same agile community.

If we all agree that we do what we do to make the world a better place of inclusion and diversity, then we are all part of the same agile culture.

If we all agree that no matter what method or framework you adopt you still aim to continuously improve, then we are all part of the same agile family.

ScrumCraft with Agile Education

ScrumCraft joins the global Agile Education Program powered by Scrum Inc.

The Agile Education Program powered by Scrum Inc curriculum was developed from Dr. Jeff Sutherland and Scrum Inc.’s 20+ years of experience delivering twice the value and impact at half the cost in organizations around the globe. Only Scrum Trainers by Scrum Inc are authorized to teach this curriculum and certify students through the Agile Education Program. Course curriculum includes emphasis on Lean Principles, Patterns of High-Performing Teams, Scrum@Scale, and lessons from real-world implementations.

ScrumCraft will be delivering Scrum@Scale training courses as of October 2021 starting with Registered Scrum@Scale Fundamentals and Registered Scrum@Scale Practitioner.

Registered Scrum@Scale Fundamentals (RS@SF)

Who: The time poor Executive or the Scrum@Scale curious who want to know more about Scrum@Scale before investing in a 2 day course.

When: Monday evening, 25th October for 4 hours

Cost: $499

Registered Scrum@Scale Practitioner (RS@SP)

Who: Geared towards scrum masters, product owners, executives or anyone with knowledge of scrum looking to scale.

When: 14 hours over 4 nights starting Monday 22nd November

Cost: $2,500 or $1995 for the early bird if booked prior to the 22nd October

If you want to discuss the right option for you please reach out on social media or though our website contact options.

ScrumCraft partners with Zip

Since its beginning, ScrumCraft has held a single mission which is to demystify agile at scale. As we grow we recognise that our mission should grow us to reflect our ongoing commitment.

One of these is at the core of what we do naturally because it is “built-in” to our values and principles. We want to ensure that everyone has the same opportunity. With that in mind, our next slice is to make training opportunities more accessible.

There is nothing worse or stressful when you hear about a great training opportunity, only to be disappointed when the dates dont line up with your finances. You either end up missing out or it impacts your savings goals and you have to commit to eating steamed rice until you catch up financially.

In finding a solution for our customers we wanted to strike a balance. We wanted customers to have access to funds when they wanted to attend training, without the high interest rates of a credit card.

That is why we partnered with Zip. With Zip we feel we have found that balance.

Zip|Pay
Train now, Pay Later
1. Nothing to pay today
2. Interest free always
3. Flexible repayments

Using Zip will allow you to attend training now and pay it off in manageable repayments that wont wear out the rice bowl, starting from $10 per week.

For further information on our courses check our our services and for further information on our Zip payment option click here.

Break the Chain of Conflict

Emerging workplace etiquette and maintaining a safe working environment…

People adopt different tactics to deal with emotional interactions and responding to emails emotionally can have long lasting effect on working relationships.

Favouring Individuals and Interactions over Processes and Tools.

Receiving an email with emotionally charged language or aggravated tone can really impact your day and can have flow on impacts to others around you. Not forgetting the direct relationship impact between the sender and receiver.

It pays to give some thought to the intent for passing on these feelings electronically and causing a chain reaction or domino effect.

The development of a safe working environment starts with building trust and the best way to build trust is transparency through telling the truth. Safe workplaces are foundational to building high performance.

Photo by Anna Shvets on Pexels.com

Ask yourself:

Are you typing an emotive email because you have been the recipient of poorly delivered feedback yourself?

Are about to continue the same reactive or emotional way because of how it made you feel?

If someone has suffered a slip-up, don’t stress, use this approach to respond!

STOP! You have yourself an opportunity to change the future! Why pass the vibe on to the next person or retaliate by responding. Give some time for reflection. Take a few deep breaths and regroup.

LINK! Try to uncover the motivation or the connection between the sender and the emotional content. Read between the lines, let your existing relationship with them and your knowledge of them help to discover the issue or the why?! Think of the person not of the problem.

INTENTION! Assume positive intent,  reflect on positive interactions you have had with the person and allow yourself to rise above this unusual event with grace. Consider your next steps carefully. Will you be part of the domino effect? Or will you have the courage to be different?

PERSPECTIVE! Keep it short, leave titles at the door, focus on well-being. Take some time to respond and select just one item to keep the interaction simple. Type your response but don’t send it. Get yourself a glass of water and come back, review it again before sending. This breather might provide just enough time for a fresh perspective.

Be the change you want to see!

You don’t even need a poor interaction or conflict to start making a difference to others around you. Start today, think about the value you can provide by improving your interactions and deepening relationships through being hyper-considerate. 

  • Pick up that task that doesn’t belong to you
  • State you have capacity to help during stand-up
  • Pair work with someone you have not paired with before
  • Ask a teammate if they are ok if the look a bit off
  • Choose a retrospective action and take the lead
  • Contribute to someone else’s development where you can
  • Donate your time to a benefit others
  • Use appropriate salutations in electronic communication
  • Be pleasant and buck ugly trends

Start with something small, start with something easy, start with just 1 thing, but whatever you choose…just get started!

ScrumCraft Joins the Scaled Agile Partner Network

29th January 2021

Australia and Asia Pacific

ScrumCraft announced today that it has joined the Scaled Agile Partner Network as a Bronze Partner. This worldwide network includes transformation and platform providers who help enterprises facilitate and accelerate business results through adoption of the Scaled Agile Framework ® (SAFe ® ).

As one of the world’s leading framework for enterprise agility, SAFe helps businesses address the significant challenges of developing and delivering high-quality software and systems in the shortest sustainable lead time.

Where Individuals & Interactions really do come before Processes & Tools!

“Working with best-in-class partners like ScrumCraft represents our commitment to helping software and systems-dependent enterprises improve time-to-market, quality, and employee engagement,” said Dean Leffingwell, creator of SAFe and cofounder of Scaled Agile, Inc. “By incorporating SAFe into their solution offering, ScrumCraft is enabling the world’s largest organizations to become more Agile in the marketplace and more competitive in their industry.”

About ScrumCraft

We love agile, I mean we really love agile! It has provided us so many fantastic opportunities and experiences that we cannot help but want to share its awesomeness with others and provide them an avenue to grow as well. That is why, at ScrumCraft, #welovewhatwedo! We are on a mission to demystify agile at scale and help organisations and individuals connect with their inner awesome to meet complex challenges head on.

About Scaled Agile, Inc.

Scaled Agile, Inc., is the provider of SAFe®, the world’s leading framework for enterprise agility. Through learning and certification, a global partner network, and a growing community of over 450,000 trained professionals, Scaled Agile helps enterprises build better systems, increase employee engagement, and improve business outcomes. Scaled Agile is a contributing member of the Pledge 1% corporate philanthropy and community service movement. For more information on Scaled Agile and SAFe, visit scaledagile.com.

Lean, Agile & the Pandemic

I have been watching the news of late and thinking about the potential of Lean and Agile learnings that may exist in societies response to world events…to be honest I do this all the time, news, movies, TV series, books, songs, you name it, I am always seeing examples or hearing quotes and feel inspired.

Here in Australia we have been watching the news about the production of the COVID vaccine which is said to be as close as Feb21 with around 4 million doses. There are 2 thoughts here:

1. Testing & Production

I would love to lift the lid and look under the bonnet of the process for testing and production. I feel like there has been a big focus on speed to market, where else could we possibly need greater speed to market than here, right?! But it would be great to hear about what challenges and how improvements were put in place to minimise bureaucracy and eliminate delay in process. Imagine what could be achieved if we applied the same or similar approaches when an outcome was not as life threatening.

Photo by cottonbro on Pexels.com
2. Iterative Release

There are approx. 25.5 million people in Australia. It is said the first COVID vaccine batch of 4 million will be ready in Feb21. This will likely, and should, be prioritised to those in the highest and medium risk categories first such as those that are over 70, recently had organ transplants or have a disease that puts them at risk if they were to contract the virus. Is 4 million the right batch size? It seems small enough, but what if the first million was to be distributed as production continued, could this help prevent the spread faster? What is the optimum batch size when the cost of delay is so high?

Figures from the ABS show in 2019 that 16% of the Australian population were 65 and older so maybe 4 million is based on catering for the over 70’s first.

Photo by Artem Podrez on Pexels.com

It is possible with the new strain in the UK starting to be identified in other countries, and the potential that the virus could evolve or mutate again, we could be looking at a cycle of jabs like to flu shot to keep up. The ability to be adaptive, flow focussed and increase the speed of distribution are all important.

This is a serious topic and, like many, my friends and family have been impacted by change due to COVID. I mean no offence in offering these thoughts. Situations like this get me thinking about improvement and I do believe it is an opportunity to learn about what has worked well in this case study so we can inspect and adapt.

I would imagine others have had similar thoughts.

Look after yourselves and be safe!

How Do You Measure Business Value?

Over time there have been many different ways I have seen agile projects or scrum teams measure value. The most important criterion is that it needs to be fit for purpose and usable, easily repeatable throughout the project life-cycle and teams cadences as well as relevant to the project resources, business stakeholders and end customer/user alike.

Photo by Pixabay on Pexels.com

Challenges often present early in establishing value scales as team members challenge what is important to measure and how to measure different value criteria. The best approach, as is the case in almost all agile team formations, is to get the team agreement early to “just get started“. Start simple and then refine as you go. Create an initial prototype even if you cannot agree on the value ratings and learn what needs improvement by using the prototype, reviewing feedback and improve the process or model as you go. If you are starting to look at business value once a project has kicked off a good way to test out your prototype is to use historical data such as delivered user stories, put them through your prototype and then compare the results with the stories that may have been deprioritised during backlog refinement.

The benefits of starting with the simple model, even if it is as simple as suggesting a single numerical scale of 1 to 10 (or use Fibonacci as you would for story points 1,2,3,5,8,13,20), is that everyone can easily follow how to use it as it is familiar. The downside of this is that the team will often debate heavily around what the difference is between one persons 7 compared to another persons 7 etc. This is common, and an opportunity to have that exact conversation in the context of the item being discussed (lets say it is a story being rated for business value). This will give a real life example of how the prototype is being used and will generate insights on how the process might be incrementally improved. At the very least it starts to establish team thoughts on what a “7” actually is and relative value estimation starts to evolve.

So what do you do when peeps cant agree in a relative estimation model?

The answer in my experience is you need to move to a less subjective model. My advice is always to introduce change in consumable bite size pieces, iteratively. Don’t jump straight to a model that locks people down to a value scale that is dictated by directly quantifiable data values unless this was easily achieved at conception of the prototype. This can lead to teams feeling like they need to conduct high levels of detailed analysis up front around justifying business benefit at a story level and is not repeatable or sustainable.

One of my favorite models to use as a starting point in a baseline measuring system is the WSJF model as outlined in the Scaled Agile Framework (SAFe). WSJF is a mouthful of an acronym but stands for Weighted Shortest Job First, essentially this model compares the value (SAFe term being Cost of Delay) with the effort to complete the delivery of this value. The goal is to select the highest value reward with the lowest effort to complete. Another way of looking at this is lowest effort vs. highest return, therefore these product backlog increments (PBI’s) should go first.


For further info on WSJF see the SAFe website: https://www.scaledagileframework.com/wsjf/

Lets look at this concept firstly at it’s most basic, single backlog, single value stream level. In a fit for purpose approach the criteria can change to what ever the customer wants to measure as being valuable. In the original SAFe framework the criteria are User-Business Value, Time Criticality and Risk Reduction and/or Opportunity Enablement. The sum of these criteria then get divided by the effort or story points to come up with a figure that can be used at a glance to compare items across the backlog. For example:

In commercial business environments it is easy enough to put quantifiable value set behind the scale and therefore introduce less subjectivity. Opportunity Enablement in a Fibonacci scale of 1 to 20 for example can be linked to a dollar value (e.g. 1= <$50k and 20= >$5m).

In this example the user value was of medium benefit, it had low time criticality but high in opportunity generation.

What happens if your project is less attached to quantifiable measures and outputs?

You may find yourself working on more qualitative driven projects which are harder for the stakeholders to quantify benefit, however you still need to have conversations around business or customer value. You can still use a multi criteria approach based on the value drivers for that project but you may need to start with a less descriptive scale increments and adopt more of a low, medium, high value rating system.

The intent behind the criteria should be reflected in the scale language.

In a recent project the product owners short listed a bunch of value measures and then prioritised these down to a set of 4 criteria being Customer Experience (CX), User Experience (UX), Time Criticality (TC) and Risk Reduction (RR). To set the scale for each they used terms that meant something to them or their customers but still keeping the scale simple so that it was easy to use…whilst maintaining relevancy.


The team then simply used the scale of 1 being lowest and 20 being highest for each criteria.

So what happens next?

Backlog prioritisation sees the Product Ownership team, guided by the Product Owner & Business SME, evaluate each PBI (in this case User Story) relative to each other across each value category. This requires a starting point for relativity. SAFe suggests the team should identify the lowest value rated PBI in each category and give it a 1, thereafter every rating has a comparison point. Just as good is getting the team to elect the PBI they feel they know the most about and rate all categories for that Story. Then the story and all of the rated categories becomes the reference point for business value rating.

The figure above assumes that the team has also been involved in story point estimation. The business value is then created as a sum of the 4 categories. In this example the logical sequence of priority would be Story C, Story A and then Story B. Story C has the highest business value and lowest story points and therefore meets the highest reward vs lowest effort criteria. As we have strayed from true WSJF its interesting to note the WSJF on Story C would be 12 (36/3=12). Stories A & B have the same business value but Story A is only 5 story points so takes pole position. To reinforce this selection Story A = a WSJF of 6.4 and B = 2.5.

A good friend of mine and I were solving a particular problem for a customer and we were looking at ways to improve their business value rating system. For the purpose of this tale I am going to call him Andy, as that is his name. We were reviewing the value ratings of epics across the portfolio and observed that each product owner had very strong views that their epics scheduled next on the roadmap were all of high business vale. That could be because they were higher on each individual product owners backlog and as such of highest importance to that product owner, and fair enough right? But this introduced priority conflicts that were hard to defend with a single business value figure as they were only reviewing the business value sum for each others epics not the category breakdown. If the maximum business value number was 100%, everyone’s epics were 80% or higher.

Now for some fun… Its time to call the doctor!

To combat this we needed to come up with something that would expose value over effort, avoid concealing the rating of each category from only reviewing the sum and use something that would generate enthusiasm in its use. And the business value Blood Pressure chart was born.


By keeping each value category rating visible, the priority conversation can be had at a more granular level.

Based on the concept of blood pressure measurements being articulated as 120 over 80, if you’re lucky ;), we wanted to carry this concept through to plotting your results on a hospital chart. In this example the reading was 36 over 3.

With the Value & Effort exposed they can easily be plotted on the blood pressure chart. The blood pressure chart is based on a version of a prioritisation matrix.

Blood Pressure Chart

This type of chart or approach is not new but giving it a theme adds to engagement and collaboration. The line dividing the quadrant will need to move based on your scale and rating averages.

Its always good to review the process, the measures and outcomes in retrospectives to ensure they are as accurate as the initial vision and re-calibrate.

It is good for transparency to have the chart made visible in the team area and not hidden away in a digital location where its not accessible to the team and wider stakeholders.

Example chart using Stories A,B & C.

This method has been very successful when managing multiple value streams under a program or portfolio or a single project, and it’s fully scaleable when required. Finding ways to gain consensus across multiple Product Owners and project objectives can be tricky to say the least. Whether you have an org structure that has a Group Product Ownership structure or separate product owners needing to collaborate on priority, a common business value system is hugely beneficial in generating the right conversations and transparency in an effort to remove information masking by more subjective methods.

What do you use to measure business value?

What has worked well or not so well?

Please share or provide thoughts on this article in the comments.

Cheers Jas