Managing distributed, part-time and virtual teams – Part 3 … Prioriti[s|z]ation of ideas, features and stories

We continue from Normali[s|z]ed estimations and Portfolio, flights, teams, epics and VSO, venturing in the prioritization of ideas, features and stories. What are we supposed to do, when and what must be done first?

our context

Commonly referred to as initiatives, investment themes, or product themes, we work with Ideas that represent the solution value propositions as requested by the ALM community and stakeholders, who have great ideas. It helps to visualize solutions as the beginning of something new (dawn), when it is in full operation (daylight) and the period during which the value of a solution has faded (dusk) to highlight the risk and value. Ideas need to be harvested, groomed, and prioritized to allow the triage group to understand their value proposition and decide how to invest in new (dawn), future, existing (daylight), or retiring (dusk) solutions. For example, investing in a solution that is in the dusk phase is potentially a high-risk and short-lived investment. Remember the saying “the darkest hour is just before the dawn” (Gary Martin, 2014) when faced with the challenges of embarking on a new project.

Dusk solutions are the biggest challenge for the ALM Rangers, who “plug holes” for missing features or guidance, which may not be a hole once the “filler” solution is completed. We therefore rely heavily on our product owner (PO), from the product group, to keep us aligned and not waste invaluable bandwidth on a solution whose sun is setting.


We favour simplicity and mandate the use of VSO, using Fibonacci numbers to define the (1) “business value” of the Epic, Feature and Story work items, in relation to the objectives and other features. The higher the value, more valuable the feature. You will note that the (2) Epic business value is “odd”, more on this later,  (3) Features have a business value, (4) as do Stories. As we cannot yet customise the process template on Visual Studio Online and the Epic type is not yet available, we re-use the Feature work item type with an Epic tag, to represent an Epic. 

why prioritize?

We have to deliver value, as quickly and as much thereof as possible. In today’s rapid evolving world, a feature that is invaluable today, may be retired in 6 months or less. However, if we imagine ourselves in a restaurant … getting the desert, before the vegetables, followed by the soup and rounded off with a Steak sizzled to perfection would not make us happy. Receiving everything together, cooked to perfection is probably better, but would still not receive your five star rating. It is therefore important to determine the value of each deliverable and the dependencies, so that you will receive a perfect starter, main course (including vegetables and the Steak as one meal) and rounded off with a desert.

Two common methods for planning and prioritization to consider:

  • Shortest Job First (SJF) method (Wikipedia, 2014) is useful when the cost of delay is equal and recommends doing the smallest story first. 
    Cost of delay B
    Scenario 1 shows the optimal sequence with the least cost of delay. Scenario 2 not only has a higher cost of delay, but a higher risk for the smaller tasks to lose their value over time. Most importantly, scenario 2 will let the user wait the longest for shippable increments.
  • Weighted Shortest Job First (WSJF) method (, Dean Leffingwell, 2014) is useful when stories have different cost of delay and required effort, which is common. It involves measures for User Value, Time Value, Risk Reduction / Opportunity Enablement Value, and Job Size and is defined by the following formula:
    WSJF = (User Value + Time Value + RROE Value) / Job Size,
    where RROE stands for Risk Reduction Opportunity Enablement

?.1 Have you used either of these methods with success?

what is prioritized?

We prioritise objectives, features and stories using a business value represented by Fibonacci numbers and Ideas using an evolving triage score. The higher the value, the higher its perceived business value.


Objectives are important to contextualize the team goals, create a solid foundation and baseline for feature and story planning and tracking, and evolve the acceptance criteria for the release and its features. Here is an example from the ALM Rangers Treasure Map team:

  • Real-time update of treasure map metadata, without the need to publish and install a new release.
    BV:8 (BV-Business Value)
  • Release by June 2014 and host a TechReady 19 Chalk Talk.
  • Optional metrics of user navigation and popularity of islands, using Application Insights.
  • (Exceeded) Practical guidance / blog on the use of Application Insights to capture metrics in a Windows Store application.
  • (Exceeded) Improved navigation in terms of UX and contents of treasure islands.


With ideas we use the vote count from UserVoice for community ideas and 800-999 for strategic ideas as the business value. Using this value and the priority (1-4) we calculate a score for ranking:
Score = (( 5 – Priority) * 1000 ) + BV ) / size

?.2 The score assumes that strategic ideas will rule the backlog unless we have a community vote with 800 or more votes. Does this sound reasonable from a community point of view?

Features and Stories

Looking at the example hierarchy of an Epic (idea), six associated Features and one parked Feature from the ALM Readiness Treasure Map team for version 3 release. It is evident that both the Features and their business value (BV) relate to the release objectives.

backlog - portfolio

Stories are prioritised within the scope of of its patent feature, to ensure that the vegetables are prepared and coked, before we place the Steak on the grill/barbeque/braai.

who and how to prioritize?

The who is simple to answer within our context. The product owner (PO) prioritizes the epic (idea), features, stories and objectives.

The how depends on the availability and bandwidth of the product owner. We definitely prefer to hand a list of non-prioritized artefacts to the product owner for prioritization and react. To reduce the impact on the product owner (PO) bandwidth, which is a precious commodity within our context, the scrum/ruck master and project lead often meet to prioritise and document the items before handing them to the product owner for validation or fine-tuning.

?.3 Who, what and how are you prioritizing?

reference information

More information n program managers, flight board and our VSO dog-fooding can be found in this section.

?.4 Are these tours of how we work and use VSO of value to you?

Comments (0)

Skip to main content