Cloud and Software Architecture, Soft skills, IOT and embedded
Visual Aids when Prioritizing Work and Calculating WSJF
Get link
Facebook
X
Pinterest
Email
Other Apps
WSJF is an analytical work prioritization method that attempts to ensure the delivery of the most value in the least amount of time. It takes into account a Business Feature's value as weighted by the cost of delay and cost of delivery. WSJF scores are re-evaluated to continually reprioritize the backlog to ensure the highest value items are at the top of the work queues. Programs are always working on today's most valuable work and not some work that was important at some time in the past.
In my opinion, one of the most interesting things about it is that the process completely ignores sunk costs continually making financial decisions, a fundamental principle in Lean. Troy did a great job making this approachable.
Codifying Prioritization based on Value and Effort
The WSJF is based on a simple formula that takes into account two values generated by product ownership and engineering. Teams meet in prioritization sessions and calculate both values and then sort all your deliverables based on the resulting scores. This automatically gives you a value to sort your backlog. The values should be recalculated on a regular basis as additional work is fed into the funnel. This may cause previously prioritized, but not committed, work to get pushed lower in the backlog.
Cost of Delay / Relative Size
The agile mindset views the Cost of Delay as the most important part of this equation. A CoD must always be calculated and used in prioritization.
There are some situations where you manually change the order in cases where a dependency ended up prioritized below some business feature that depended on it.
Most people are visual thinkers
We want to provide visual methods for managing the Agile process, really any process where we want people involved and participating in the decisions. The backlog board, planning stickies, Kanban and other tools are manifestations of providing visual dashboards and tools. Even things like Fist of Five provide simple ways of making decisions and gathering input that people can see.
Sizing and Prioritization are fundamental tools for Agile processes. Teams take on this work in every planning cycle at the program level and at the team level. WSJF is interesting because the final WSJF score takes into account the Numerator and the Denominator of the CoD/Size calculation. Product Ownership and Delivery must somehow come to an agreement on backlog and be able to describe how they got there.
It is important to prioritize based on the relative cost and size of tasks against each other. The absolute value is less important than the value relative to other potential work. Troy presented a graphical way of calculating and visualizing relative priorities and relative sizing. We create scoring boards that let stakeholders position Features relative to other Features taking into account aspects of the Cost Delay or Work Cost. The teams can move work items around on the board until they are in agreement. The overall prioritization score (WSJF) is derived from the item placement on the two boards.
Cost of Delay
Place each of your features on the Cost of Delay board ignoring the numbers in the squares. The numbers are used for the numerator when calculating the WSJF.
Some teams place them linearly on a Cost-of-Delay line. I've found that having two dimensions makes people feel comfortable that they are taking into account the value and when it needs to be delivered. A single variable tends to cause angst while people try and take both into account in their heads.
Place each item on the table. You can always move them around once you have got them placed. This can happen when people need to re-think the early items on the board relative to ones that were placed later.
Relative Sizing
Place each of your features on the Sizing/Work board ignoring the numbers in the squares. The numbers are used for the denominator when calculating the WSJF.
Some teams place them linearly on an effort line. I've found that having two dimensions makes people feel comfortable that they are taking into account the nuances of the both the amount of work and the complexity of that work. Some tasks involve a lot of grunt work while others may have little work but require a lot of coordination or design in order to be delivered A single variable tends to cause angst while people try and take both into account in their heads.
Place each item on the table. You can always move them around once you have got them placed. This can happen when people need to re-think the early items on the board relative to ones that were placed later.
Doing the Math
Transfer the CoD and Relative Size values to a spreadsheet and calculate the WSJF score. Then sort the work based on that score. Your backlog is almost automatically prioritized for you based on the output.
Cost of Delay
----------------
Relative Size
Taking into Account Dependencies
Teams may have to manually change the prioritized based on Non Functional Requirements or Feature interdependencies.
Ex: Adding a payment engine to a website is important for revenue but worthless until we have an actual running website that users can come to.
Ex: Adding a payment engine to a website is important for revenue but we need an authentication and authorization mechanism in place that protects the user's account from takeovers or fraud.
YouTube It
References
I first saw demonstrated by Troy Lightfoot https://prokanbantraining.com/troy-lightfoot-kanban-instructor
This blog article articulates Troy's process https://www.agile101.com.au/post/weighted-shortest-job-first-wsjf-prioritisation-method
The Scaled Agile Framework site provides a good description of WSJF https://www.scaledagileframework.com/wsjf/
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with gadget drivers that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device. All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update or Update Driver does not install the RNDI
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time. Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM. You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop. Docker Desktop has two of its own WSL modules that need to be accounted for. You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory. The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaults to a maximum RAM size of 5
The Apache Tika project provides a library capable of parsing and extracting data and meta data from over 1000 file types. Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk. I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents. Preconditions An AWS account. AWS access id and secret key.
Comments
Post a Comment