The 3 most important questions to ask your product stakeholders.

Asking your stakeholders the right questions early on in product development is critical to focusing discussions, encouraging product innovation, and ensuring product success. 

With the new year here, I thought it would be a good time to discuss ways to get projects off to a good start.

When initiating any project, it's good practice to get an understanding of your stakeholders challenges and project expectations.  Asking your stakeholders the right questions early on in product development is critical to focusing these discussions, encouraging product innovation, and ensuring product success. 

Product managers and analysts often start out by identifying a product's current state and eliciting high-level requirements from the product's stakeholders. Stakeholders include product owners, subject matter experts (SMEs), customers, clients, product users, partners, etc.

Some of the more common questions I hear asked are:

• What is the problem with your existing process/system?
• What do you want it to do?
• When do you need it by?
• What is your budget?

While these are all completely appropriate and necessary questions that should be asked, using these alone to drive your solution can often limit the potential value delivered to your stakeholders and can waste time and resources delivering something different from what the stakeholders expected.

Of course you want to understand the existing system and processes, but by focusing too much on an existing system's problems, you often end up with a myopic view of the stakeholder's real goals and the product itself when developing your product vision.

For projects which are designed to replace a legacy product, teams tend to assume that the objective of the project is to build the new system on time and within budget.  The result being epic, features, and user stories written to mimic the legacy system but with newer technology and platforms and perhaps a few new features.

But just getting a system built on time and within budget should not be considered the real objective. While this is definitely important, the real objective should be to accomplish something beyond the product itself.

 This leads to the first question:

1.       What are you trying to accomplish?

Because creating or amending any kind of product requires significant collaboration between development teams and stakeholders, it's critical for everyone involved to understand the context for those interactions. This requires some basic questions that need be asked at the onset.

I'm guessing a lot of those reading this have experienced this situation: Your friends and acquaintances find out you work with computers, and now is their opportunity to ask you all of those tech questions they've been meaning to resolve (this usually happens at a party).  I often get questions like, “I just upgraded my OS and can’t seem to do X in this application anymore, how do i fix it?” My initial instinct is to start out by trying to help them resolve their specific problem, but eventually, I almost always end up asking, what is it, that you are you trying to accomplish exactly? You will be surprised by the answers you get from this question.  It’s more common than not, that I find someone trying to accomplish a task either with the wrong tool for the job, an inefficient process, or both. Many times, the simplest solution is using an entirely different application, using the application a completely different way, or using some kind of external service to perform the activity.

Granted there may be some costs for involving new software, hardware, and services, which sometimes results in shock and horror that I'm even suggesting they pay for something; even if it is going to save them hours of time in the future. 

By asking your stakeholders what they are trying to accomplish first, before diving into their problems, allows you to understand your stakeholder’s goals from a business standpoint rather than from a systems standpoint, and tends to keep the conversation strategic rather than tactical.

Examples of strategic goals might be:

• We want our clients to be healthier utilizing our services.
• We want our users to find music all day that makes them happy.
• We want to create furniture for our customers that makes them feel organized and peaceful.

Get the idea?

When an entire team understands the business's strategic goals, it helps align team members during release and sprint planning processes by making it much easier to determine what features you need to focus on first, helps focus story prioritization, and also opens the team up to thinking about new and innovative ways of accomplishing these goals many times leading to disruptive solutions.

2.       Why do you want to accomplish it?

The next question to ask is, why do you want to accomplish this goal or objective?

Asking this question often reveals entirely different understandings of the product amongst stakeholders, leads to better stakeholder alignment, and gives everyone a more holistic view of the product. 

This question also helps guide your solution and architecture choices because it tends to bring out  non-functionalrequirements (NFRs) such as regulatory, system availability, volume, and performance requirements. E.g. the decision to install something locally or in the cloud.

The answers to ‘Why’ also provides support to your user stories.  In the generally accepted format of ‘As a user, I want to <do this thing> so that <I get this benefit>”. Tt’s the ‘So that’ that tends to take on a more meaningful purpose and understanding by your team, and can open up more creative and effective ways of accomplishing a task no one may have thought of before.

For example, a stakeholder may want to sort a report a specific way so that users can reconcile inventory easier.  A better understanding of the goal, may trigger a team member to suggest using a more automated approach with a scanner and/or mobile device instead of printing out a better sorted report.

3.       How do you measure success?

Finally, once the What, Why, and How are identified, you want to be able to measure the results of your new product features, and/or processes, to determine if they are accomplishing what you set out to accomplish.

In my example of helping my friends with their tech problems, I mentioned how some of them balked when asked to pony up some additional cash for a better solution.  When assessing costs, the more clearly we can demonstrate the savings your stakeholders will receive, the more justification you will have (or not have) for the cost of the solution. 

While it’s important to deliver features on time and within budget, this should not be the only method to judge the success of your project (unless of course your project was to introduce a better way to deliver on time).  You’re going to need other ways to quantitatively measure your success.  This may be measured through a variety of things such as throughput (how many customers can be serviced per day, how many widgets created, etc.), time (time to deliver, wait time, response time etc.), dollars (revenue, expenses, profit, etc), customer satisfaction (negative/positive survey comments, Net Promoter Scores) etc.  You and your stakeholder need to agree on these measurements and they are items you should be able to track throughout the project. I suggest keeping your success measurements to just a handful.

Once you have identified your success measures, you should be able to clearly demonstrate feature successes and failures to your stakeholders and to the entire team. Having this information makes it easier to communicate status and should lead to better retrospective conversations of what went right, what went wrong, and what can be done to improve things.

With your team and stakeholders understanding the strategic goals, the purpose of the goals, and how to measure your success, it should make for smoother and more innovative sailing on your new project.

Here's to new beginnings! Happy New Year.

Agile Release Planning - Aligning with Executive Management

Executive Summary:

For longer-term technology projects, a quarterly planning Kanban board will not only help with release planning, but is also a great way to align program management with executive management on releases, resource capacity planning, costing, and ongoing project status reporting.

Quarterly Planning Kanban Board. 

In a previous article, I discussed methods to break down your product epics and features that were understandable to both executive management and product stakeholders, along with how to use the SAFe weighted shortest job first (WSJF) method to prioritize these features. In this article, I'd like to discuss a clear and simple way to present your agile release plans to executive management.

As part of agile release planning, you will need to identify epics and features that will be implemented over longer periods of time.  It's said that a picture is worth a thousand words, but with the advent of many new agile tools,  too many pictures can sometimes be overwhelming and information can get buried, especially when trying to communicate plans to executive management. This often results in miscommunications and many long unnecessary status meetings. As a program and/or product manager, it's critical you find a communication approach for both you, your teams, and more importantly, you executive management, that clearly, and accurately, depicts your initiative's plan and status.

Let’s look at the previous initiative example I presented for integrating a cloud-based HR system into your existing environment to replace a legacy HR system.

A simplified set of phases of the project identified were as follows:

Integrate new cloud-based HR System

·                  Environment Setup

·                  Integrate vended application with existing legacy systems

·                  Migrate existing employee & contractor data into vended application

These phases are what I would call super-epics.

After further analysis we came up with the following sub-epics and features for the Integrate phase:

Here is an example of expanding the Employee Update epics within the Integrate phase into features.

(Super) Epic	Sub Epic	Feature	Team A	Team B	Team C	Vendor A
. . .
HR Cloud Integration	Employee Update	HR Cloud Core Data Update		X		X
HR Cloud Integration	Employee Update	Facilities Location Update	X	X		X
HR Cloud Integration	Employee Update	Telecom Update			X	X
. . .

Example Epic and Feature Analysis by Team.

Note that we are expressing our epics and features from a business standpoint and not from a technical standpoint. We know which systems are impacted by identifying which teams need to be involved to execute specific features.  So Team A might represent the Facilities system, Team B might represent the new HR system, Team C might represent the Telecom system, and Vendor A might represent the HR System's vendor.

If these were architectural epics, of course we would reference specific tools, systems etc., because from an enterprise architecture standpoint, these systems, tools, and middleware are their business. Make sense?

• From executive management’s standpoint, they are primarily interested in when the main project phases (super-epics) will be completed and how much it’s going to cost them.

• From a program manager’s standpoint, they are primarily interested in when the epics (super-epics and sub-epics) will be completed and are they on or over budget. 

Note that you can call these levels whatever you want, but the point is that what management likes to see is generally at a much higher level than what execution/implementation teams like to see, and that you just need to be conscious of this. Some tools like Jira Portfolio can help you align these differences.

Here's another way to think about it.

Keeping in-line with Dean Leffingwell’s scaled agile framework (SAFe) concepts of implementing interconnected Kanban and SCRUM boards to manage a company’s portfolio initiatives, programs, and associated projects, we get this hierarchy of epics, features and user stories where epics represent executive strategy, features represent program management, and stories represent the tactical execution of programs.

Image Source: adapted from http://versionone.com Enterprise Agile presentation. 

 To help align both program/product management and executive management for longer-term planning, and to ease management into concepts of lean and agile such as Kanban boards, epics, and features, I recommend starting off with a Kanban board based on quarters. 

Here’s the basic approach.

At its simplest, each column on the Kanban board represents one quarter and an epic is placed in the quarter that it is scheduled to be completed.  Within each epic you can include the features that are planned to be released within that epic. It’s up to you to define your definition of done for each item on the board, and everyone should be very clear about what this means. i.e. is it just user acceptance tested, or does it mean it’s been rolled out to the field.

You can include as many quarters as you want, but I’d recommend making no more than 6 – 8 quarters at a time. You can reuse previous quarters on the board about every 6 – 9 months.  This view shows only the current year, but you can include quarters from the previous year and next year as well.

Quarterly Planning Kanban Board. 

I encourage program management to maintain this as a physical board in a place where executive management will see it as well as the entire team.  For remote teams, you can also maintain this in tools like Jira and VersionOne, but just be sure that you incorporate a process to ensure this has constant visibility.

Note that an epic may appear in multiple quarters because features within an epic will likely be incorporated into different releases. You can further refine this board by using color post-its or indicators on the post-it, to indicate whether something is on-schedule, delayed, or has a major blocker, and/or you might consider adding traditional "To-Do", "In-Process", and "Done" Kanban columns within each quarter.

Additionally, horizontal columns can be used to indicate which team is primarily responsible for which feature. You might even indicate specific release trains on the timeline as well.

Quarterly Planning Kanban Board with Team Columns. 

And yes, it's not that much different than a traditional calendar, but it's familiarity and bridge into agile concepts is it's key benefit, not to mention it can easily be incorporated as a Kanban board in just about any agile tool.

Another valuable dimension that can be represented here are the points and/or hours for each feature as well as the total points or hours for the quarter and for each team over a period of time. This allows you to plan and identify team commitments, constraints, and availability, along with a rough idea of both team and quarterly estimated costs. After a quarter has completed, you might even show planned versus actual hours to help with the next period of planning.

Quarterly Planning Kanban Board with team and quarterly hourly totals.

Deciding what to include and how to manage the quarterly Kanban board is something that will evolve over time and will be determined by your project and organizational needs.

If you focus on information that maximizes the value provided to your management teams and minimizes the effort to manage the board itself and you will find that implementing a big visible quarterly Kanban board will help bridge the gap between executive management and program management and help reduce unnecessary project status meetings saving everyone's time.

I would greatly welcome your feedback and experiences regarding agile release planning and management.

Blog header Image Source: theflowcentre.com

Waterfall Development is Not a Bad Word - or When to use Waterfall in an Agile Environment.

Over the past decade, agile software development has grown exponentially across all types of organizations and industries. During this time period, having been involved in several small and large scale agile and waterfall projects involving custom development as well as third party implementations, I found that there are some cases when the traditional waterfall methodology of requirements analysis, design, build and test, is a better choice over an agile methodology like SCRUM or XP.

Implementation with a waterfall methodology doesn't necessarily mean we throw out our agile mindset (now might be a good time to refresh yourself with the agile manifesto), rather it means we still embrace these things by choosing the right development approach, based on the particular job and team.

WATERFALL DEVELOPMENT

AGILE DEVELOPMENT - SCRUM  

So, when is the best time to implement something using a waterfall methodology?

A core approach within agile methodologies like Scrum and XP, is to break effort down into small work iterations, or sprints. These sprints can range anywhere from a few days to a month, but commonly are implemented in 2 week iterations.  The purpose of iterations, is to deal with the ever changing environment and conditions that happen over the course of a project. This enables us to reassess user requirements frequently, preventing situations where a change in our environment resulted in a substantial change to our requirements after spending  months on a design.  But what if there wasn't much change happening?  What, no change?!

One of the primary examples of something that tends not to change, is when the product being implemented is something of a known quantity. This usually occurs in package applications or applications within an organization that have been implemented over and over again with regularity.

Generally in the case of locally installed package or cloud applications, the vendor tends to do some initial planning & analysis with the client to determine the core configuration of the product and it’s necessary infrastructure, and can tell the client how long the implementation & testing should take. In many cases, the vendor can even provide test cases along with test data to validate everything is working.  In cases like these, the teams that implement these kinds of products, generally should not have a need to create a backlog of user stories have daily scrum meetings, and plan things in development iterations as this would likely generate a lot of waste.

In cases where a product may need some significant customization and/or integration, cases where there are a lot of UNKNOWNS, an agile methodology tends to works best, but in cases where the vendor or internal team, has implemented them over and over, most of the variables needed to install or configure a product are well known a simple waterfall methodology should be acceptable. 

In these situations, consider following the vendor’s methodology or internal team's methodology, versus trying to squeeze in an agile methodology you normally use for custom development.

This doesn't mean your infrastructure or architecture teams should only use one methodology, what it means is that you need to match the approach to the job. So it might be possible that in one instance, a team uses scrum or Kanban, and in another uses waterfall.  The key is to determine what's best for the team so that the product can be delivered in minimal time with the most value to the organization.  For example, it's fairly common that large package implementations go awry, but this is primarily the result of treating the core package (known) and customizations AND integrations(unknown) the same. If we implement and test the package's core functionality first using standard waterfall and then treat the customizations and integrations with an agile methodology (stories, backlogs, iterations, etc.), we get the best of both worlds.

Remember, the first tenant of the agile manifesto is: Individuals and interactions over processes and tools. Don't get hung up on the need to apply an agile methodology to everything, apply an agile mindset to everything.

It would be great to hear about your experiences, success and not so successes too.

5 Steps for Using SAFe’s Weighted Shortest Job First Ratio (WSJF) for Backlog Prioritization

Exec. Summary:
By combining a ratio of business value to effort with the use of planning poker, a simple and standardized ratio can be used to help guide organizations in the process of backlog prioritization.

After wearing many SDLC hats over the past twenty plus years in the tech consulting arena including developer, data architect, systems analyst, business analyst, project manager, and product manager, I have come to greatly appreciate many of the principles found in the agile framework and its supporting techniques.  One of the more intriguing agile developments is applying agile not just to development teams but applying it upwardly throughout an organization including executive management.

Once such development in this field is Dean Leffingwell’s Scaled Agile Framework (SAFe) which uses interconnected Kanban and SCRUM boards to manage a company’s portfolio initiatives, programs, and associated projects.  A key idea here is that an organization’s initiatives can be broken into quarterly sized chunks of work,or epics at a portfolio level (management strategy), these epics can then be broken into monthly sized chunks of work, or features at a program level (coordination), and features can be broken into sprint sized chunks of work, usually two-week user stories, at the project team level (execution).  The actual durations of these three levels is really dependent on what your teams are comfortable with when doing work estimation.


Image Source: adapted from http://versionone.com Enterprise Agile presentation.

One of the more difficult tasks to perform is a consistent way for management to prioritize business and architectural epic and feature backlogs. SAFe proposes an interesting approach called Weighted Shortest Job First (WSJF).  In a nutshell WSJF is a ratio of an item’s business value to the size of effort to implement it (duration).  Items with a higher ratio bring the greatest business value soonest and therefore should be implemented first.  If you are already familiar with these concepts and want to get to the 5 steps, you can go to Step 1 here.

SAFe suggests that business value be driven by a concept called Cost of Delay (COD). Essentially opportunity cost to delay implementation of some functionality.  COD will be specific to your situation.

SAFe breaks business value into three categories:
1) Value to the User and/or Business – This includes impacts of delays on revenue, expenses, penalties, market share.
2) Time Criticality to User and/or Business – The impact of implementation delay to deadlines, regulatory requirements, user trust, and other dependent projects.
3) Risk Reduction or Opportunity Enablement – The risk reduction or unlocked potential of business opportunities that may be lost or gained based on delaying the release of functionality.

For work effort, the bottom half of the ratio, ideally you want to express this in terms of time. 

So the resulting ratio of a functional requirement looks something like this:

WSJF = User/Business Value + Time Criticality + Risk Reduction / Time

Business value is measured in relative points, like Fibonacci story points, and time is measured in work duration. e.g. days, hours, etc.

The higher the ratio the higher the value of the item being evaluated should be to the business.
If some of these factors makes sense and some sound difficult to quantify, I wholeheartedly agree.

On a recent engagement with a well known movie and game rental company, let’s just call them Bedrocks,  I guided a pilot project to test out some SAFe concepts to see how well they would fare for managing several projects and providing prioritization guidance to the implementation teams. We liked the concept of the WSJF but arriving at the necessary values seemed challenging.
Participating teams included a newly formed Enterprise Product team,  and one of the architectural platform teams. Note that Bedrocks was just one of a few lines of businesses managed by Bedrock’s parent company. The Enterprise Product Team which was part of the parent company, oversaw product management for all lines of businesses, and the architectural platforms, also part of the parent company, served all lines of businesses as well.  This is actually a critical point because a method was needed to determine which line of business got access to a limited set of enterprise technical resources first.

We visualized our Epics on a Kanban board that used 4 quarters to plan our epics (Q1, Q2, Q3, Q4) and those epics linked to a child Kanban board of features represented in SDLC phases (Ready for Analysis, Analysis, Design, Build, Test, Ready to Deploy, Deploy). Don’t get too caught up in this part, this will be specific to your own environment and I’ll discuss visualization in another article.  The key to using this process is learning how to break down your work into manageable chunks that are understandable by the users  at the Epic level (executive & program/product management) and the users at the Feature level (program/product management and project management).
To attack the complexity of this process we followed the keep it simple rule.
Before even touching a Kanban board we created our own spreadsheet to manage program epics, features, and WSJF ratios. 

Here are the five steps we took to to aide us in prioritizing product features from multiple projects leveraging the Weighted Shortest Job First (WSJF) ratio.

Some Assumptions:

• Executive Initiatives consist of one or more programs.
• Programs consists of one more projects.
• All organizational programs and their associated projects that affect our pilot implementation teams are known.
• Epic sizes should be no more than 3-4 mos.
• Features sizes should be no more than 4–5 weeks.
• Product Owners, Product Managers, and Technical team leads and architects impacted by a program are part of the epic and feature breakdown, estimation, and prioritization process for that program. 
• You may decide to include some relevant project managers as well if it will help you define the pieces of the project.

Step 1: Break your Programs into Epics
For each project within a program, everyone in the room will need to agree on the major phases of functionality required to implement each project.  So for example, if you are integrating a cloud-based HR system into your existing environment to replace a local legacy system, some of those hi-level phases might be something like this:

• Environment Setup
• Integrate vended application with existing legacy systems
• Migrate existing employee & contractor data into vended application

Determine if each epic is inside approximately 3-4 months of work, preferably 3 or less.  This is where the tech leads and architects come in handy.
If not, break the items down further into sub-epics. Don’t get hung up on the durations just yet, you’ll be able to come back and correct this later.
So maybe further discussion produces the following:

• Environment Setup 
• Integrate vended application with existing legacy systems
  • Employee New Hire 
  • Employee Update
  • Employee Terminate
  • Contractor New Hire
  • Contractor Update
  • Contractor Terminate

• Migrate Employees
  • Employee Core Data (name, role, team,  phone, supervisor, etc.)
  • Employee Benefits
• Migrate Contractors

When you populate the WSJF spreadsheet, if something has a parent and sub-epic enter them in the Epic and Sub-Epic columns respectively.

Here are the ten epics we have so far:

Epic	Sub Epic
HR Cloud Environment Setup	n/a
HR Cloud Integration	Employee New Hire
HR Cloud Integration	Employee Update
HR Cloud Integration	Employee Terminate
HR Cloud Integration	Contractor New Hire
HR Cloud Integration	Contractor Update
HR Cloud Integration	Contractor Terminate
HR Cloud Data Migration	Employee Core Data
HR Cloud Data Migration	Employee Benefits
HR Cloud Data Migration	Contractor Core Data

You might have expected me to reference each  legacy system that needed to be integrated with at this point, but I didn’t for good reason. In general, you want to express your epics and features in terms of something the user will understand when validating if the system works and users generally understand vertical slices of functionality easier rather than which systems or databases need to be plugged into. In the case of architectural epics, because the users who will verify the system works properly are technical people, the epics and features may appear to be very technical. The first epic in this list ‘HR Cloud Environment Setup’ is likely an architectural epic where features might be to ‘Setup Dev Environment, ‘Setup Test Environment’, etc. There may even be architectural epics to set up new data centers and/or middleware as well.

Expressing things in vertical functional slices also helps the user prioritize easier and let’s us know when something is truly done.
We’ll see shortly how we know which systems are affected.
Step 2: Break your Epics Into Features
Take each Epic and break them into logical chunks of work that can be accomplished in 3-4 weeks.
Let’s take a look at HR Cloud Integration – Employee Update
When we edit an existing employees name, team, phone, desk location, or supervisor, we may want that information to show up in the employee directory. Here are some sample features related to this epic.

HR Cloud Integration – Employee Update Features:

• Cloud Core Data Update (name, team, role, supervisor)
• Facilities Location Update (building, floor, office#)
• Telecom Update (desk phone, co. mobile phone)

The HR system is the source system of data for things like name and team, but in some cases there may be other systems like Facilities, and Telecom which are the source system of an employees location and phone number respectively and changes to that data must be sent to the HR system and perhaps other consumer systems but we’ve still expressed this as vertical slices of functionality that may or may not be restricted to one system.  You may also have to break your features into sub-features if they don’t seem like something you can get down in about 4-5 weeks.

Starting to get the idea here?

Before you can continue, the technical leads and architects should go thru each feature and identify which teams may be impacted (i.e. have some work to perform) relative to each feature.  You can enter this in the WSJF spreadsheet template by listing each team in it’s own column heading and then placing an ‘X’ in the cell corresponding to a feature. Teams may be architectural teams, development teams, vendors, etc. I’ve hidden the other Epics for simplification.

Epic	Sub Epic	Feature	Team A	Team B	Team C	Vendor A
. . .
HR Cloud Integration	Employee Update	HR Cloud Core Data Update		X		X
HR Cloud Integration	Employee Update	Facilities Location Update	X	X		X
HR Cloud Integration	Employee Update	Telecom Update			X	X
. . .

Identifying the teams will make it very clear what resources are needed, which systems are impacted, and where user stories needed to be written to complete a vertical functional slice. You could potentially list systems instead of teams but the way things were structured at Bedrocks there were dev teams responsible for systems and some teams that provided general platform support like Database Admin/BI, and Enterprise Infrastructure (networking). In a ideal agile world their would be one co-located team.

Step 3: Have your product owners use planning poker to assign feature business value.
Once you feel you’ve documented all of your epics and features it’s time for the fun part. If you discover some new epics and features later, no worries, you’ll just need add them and prioritize these as well.
Using the spreadsheet provided, your product owners, program managers, and possibly managers need to go thru each feature and assign a relative score based on the Fibonacci series in terms of value.
Everyone should understand the concept of cost of delay and discuss the different kinds of value that a feature may have.  We felt it was far easier to just have one score versus different scores for each type of business value as SAFe suggests.  To arrive at that one score when multiple people are involved, I highly recommend planning poker.  We used the following values (1,3,5, 8, 13, 21) but you can use any range you want.
By using planning poker, it provides a great platform for managers of different systems to discuss why they think one feature is more important than another.

Step 4: Have your technical leads use planning poker to assign feature T-shirt sizes (high level estimates).
The next step is to have your technical leads and architects identify high-level T-shirt sized estimates for each feature.  If you have more than one technical lead or architect involved in this process, I recommend using planning poker in the same way you did for business value. Another chance for great discussion amongst all of the tech leads. This also let’s different teams get a greater appreciation for what another team does and/or input it needs to do it’s job, especially when considering integration of systems.

Before beginning this step you’ll need to agree on your work-effort sizes, assign an expected duration to each size in days, and optionally a relative point value. 

Here’s how we did it:

T-Shirt Size	Time (days)	Story Points
XS	1	1
S	7	2
M	14	5
L	30	8
XL	60	13
XXL	90	21

T-shirt sizes provide a very general way of describing effort without getting into too much detail.
Step 5: Review your WSJFs and Feature Dependencies to determine the order of your Feature Backlog.
Now that you have identified the business value and rough time estimate for each feature, you can now calculate your Weighted Shortest Job First (WSJF) ratio. Using the provided WSJF spreadsheet, your ratio will be automatically calculated for each feature. 

Epic	Sub Epic	Feature	Bus Value	T-Shirt Size	Time (days)	WSJF	Story Pts
. . .
HR Cloud Integration	Employee Update	HR Cloud Core Data Update	21	XL	60	0.35	13
HR Cloud Integration	Employee Update	Facilities Location Update	5	M	14	0.36	5
HR Cloud Integration	Employee Update	Telecom Update	13	M	14	0.93	5
. . .

As each feature is entered in your backlog you can now include the WSJF and optionally the business value and t-shirt size associated with that feature card.

An interesting side effect of using this approach is that some features will have really low values because they take a long time to implement. To increase the features value it will be necessary to break it down into smaller pieces that can be implemented in a shorter period of time. In the example above the HR Cloud Core Data Update was estimated at 60 days. Breaking it down into smaller vertical functional slices that can be completed in 30 days or less will make it easier to manage and likely increase it’s WSJF ratio.
You may also find a need to go back and re-evaluate the business value of some items that needed to be broken into smaller pieces.

The WSJF is not the only factor in prioritization and care must be taken to identify any dependencies amongst features as well. So even though Feature C may have a much larger ratio than Feature B, Feature C may not be able to be developed until Feature B is in place, or perhaps a particular team won’t be ready to implement something until later. In the WSJF spreadsheet provided I included a column to identify which release the feature is expected to be part of which should aide in identifying dependencies and focus your prioritization within a release.

Why feature story points?
Trying to track user story points by rolling it up to a program level becomes very complex and often meaningless because different implementation teams may have different meanings behind their point system. So a 13 pt. user story for Team A will have a different level of effort compared to a 13 pt. user story for Team B. To resolve this issue, by focusing on story points at the feature level using agreed upon values amongst tech leads and architects, we now have a normalized set of story points that can be used to track velocity and cycle time for features across different systems. SAFe discusses the need for normalization of points and I think this provides an elegant way of resolving this issue. Let individual teams manage their own story points, and tech leads and architects manage feature story points.
In order for this to work however, it is necessary for the tech leads and architects to have retrospectives to evaluate the accuracy of their estimation. Often teams that require integration never get a chance to review this kind of information. So even if you don’t use story points, it’s highly recommended that some time is allocated at the end of every quarter or release, tech leads review how well they did on estimation and are able to improve their estimates for the next release.

About the WSJF Spreadsheet Template:
The WSJF spreadsheet provided leverages Excel’s grouping function so that you can expand and hide epics and features. It may be something you don’t often use in Excel and can get a little tricky to handle sometimes,  but I think you will find it helpful once you get the hang of it. You may also find it useful to copy the Epic-Feature tab for each program or for each project.
It also includes an additional tab for tracking issues that come up during this entire process so you can table them at the time of discussion and move on. Lastly it includes a tab for you to calculate a team’s iteration cost, so you can do some quick epic and feature budget estimation.
Be sure to download it to use it, it will not be functional when viewing it in Google Docs.

Final Comments:
By breaking your work down into epic sized (<= 3 mos.) and feature sized (<=30 days) functional vertical slices, and having product management work with the technical leads to estimate business value and work effort using planning poker, you can arrive at a consistent way to manage and prioritize work across the enterprise. 

A major tenant of Agile is continuous improvement. It is expected that your process for implementing an approach which uses the weighted-shortest-job-first ratio for prioritization will require some changes to the steps and resources involved than what was presented here.   I recommend you start with a small pilot project first to work out the kinks.

I would greatly welcome your feedback and like to hear about your own experiences with backlog prioritization.