Book Image

Agile Model-Based Systems Engineering Cookbook Second Edition - Second Edition

By : Dr. Bruce Powel Douglass
Book Image

Agile Model-Based Systems Engineering Cookbook Second Edition - Second Edition

By: Dr. Bruce Powel Douglass

Overview of this book

Agile MBSE can help organizations manage change while ensuring system correctness and meeting customers’ needs. But deployment challenges have changed since our first edition. The Agile Model-Based Systems Engineering Cookbook’s second edition focuses on workflows – or recipes – that will help MBSE practitioners and team leaders address practical situations that are part of deploying MBSE as part of an agile development process across the enterprise. In this 2nd edition, the Cameo MagicDraw Systems Modeler tool – the most popular tool for MBSE – is used in examples (models are downloadable by readers). Written by a world-renowned expert in MBSE, this book will take you through systems engineering workflows in the Cameo Systems Modeler SysML modeling tool and show you how they can be used with an agile and model-based approach. You’ll start with the key concepts of agile methods for systems engineering. Next, each recipe will take you through initiating a project, outlining stakeholder needs, defining and analyzing system requirements, specifying system architecture, performing model-based engineering trade studies, all the way to handling systems specifications off to downstream engineering. By the end of this MBSE book, you’ll learn how to implement systems engineering workflows and create systems engineering models.
Table of Contents (9 chapters)
6
Other Books You May Enjoy
7
Index
Appendix A: The Pegasus Bike Trainer

Work item prioritization

This recipe is about the prioritization of work items in a backlog. There is some confusion as to the meaning of the term priority. Priority is a ranking of when some task should be performed with respect to other tasks. There are a variety of factors that determine priority and different projects may weigh such factors differently. The most common factors influencing priority are:

  • Cost of delay – the cost of delaying the performance of the work item, which in turn is influenced by:
    • Criticality – the importance of the completion of the work item
    • Urgency – when the outcome or output of the work item completion is needed
    • Usefulness – the value of the outcome of the work item to the stakeholder
    • Risk – how the completion of the work item affects project risk
    • Opportunity enablement – how the completion of the work item will enable stakeholder opportunity
  • Cost – what is the cost or effort needed to complete the work item?
  • Sensical sequencing – what are the preconditions of the work item and what other work items depend upon the completion of this work item?
  • Congruency – consistency of the work item to the mission of the iteration to which it is assigned
  • Availability of resources – what resources, including specialized resources, are needed to complete this work item, and what is their availability?

Some priority schemes will be dominated by urgency while others may be dominated by criticality or resource availability. The bottom line is that work item priority determines which iteration a work item will be allocated to from the project backlog and to a lesser degree when, within an iteration, the work item will be performed.

Purpose

The purpose of work item prioritization is to intelligently plan the work so as to achieve the product goals in an incremental, consistent fashion. Specifically, the goal of work item prioritization is to allocate work items to the iteration backlogs well.

Inputs and preconditions

The product backlog has been created.

Outputs and postconditions

Work items in the product backlog are prioritized so that iteration planning can proceed.

How to do it

There are many ways to prioritize the backlog. Some, such as the MoSCoW method, are qualitative. Must, Should, Could, Won’t prioritization as described in the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK) Guide, www.iiba.org/babok-guide.aspx. In this approach, work items are categorized into the following four groups:

  • Must: A requirement that must be satisfied in the final solution for the product to be considered a success
  • Should: Represents a high-priority work item that should be included in the final solution if possible
  • Could: A work item that is desirable but not necessary for success
  • Won’t: A work item that the stakeholders have agreed to not implement now, but might be considered in a future release

Priority poker is another means by which priority may be assigned. Priority poker is similar to planning poker used for the estimation of work item effort. Planning poker is discussed in more detail in the Estimating effort recipe and so won’t be discussed here.

This recipe outlines the user of a prioritization technique known as Weighted Shortest Job First (WSJF) as defined by the Scaled Agile Framework (SAFe), see www.scaledagileframework.com/wsjf. The basic formulation is shown below.

The SAFe definition of the cost of delay is provided in the equation below. This equation differs from the original SAFe formulation by adding a project value term.

Business value is either critical or useful to the stakeholders or some combination of the two. Project value, the term I added to the formula, refers to the value of the project. For example, the reduction of technical debt may not add direct value to the stakeholders but does provide value to the project. Time criticality, also known as urgency, refers to when the feature provides value to the stakeholder. Risk reduction is the improvement in the likelihood of project success, while opportunity enablement refers to business opportunities, such as new markets, that a feature will enable.

Each of the aspects of the cost of delay is scaled using values such as the Fibonacci sequence (1, 2, 3, 5, 8, 21, 34, 55, 89, 144, and so on) with larger values indicative of a higher cost of delay. Since these are all relative measures, the summation provides a good quantitative idea of the cost of delay. For a given job size, a higher cost of delay results in a higher priority. For a given cost of delay, a larger job size reduces the priority.

Job duration is difficult to estimate until you know the resource loading, so we normally substitute Job cost for Job duration. Job cost is the topic of the Estimating effort recipe. WSJF does a good first stab at determining priority, but it needs to be adjusted manually to take into account congruency with iteration missions and specialized resource availability. The workflow is outlined in Figure 1.26:

Figure 1.26: Work item prioritization

Select the next work item from the backlog

Starting with the first work item, select the work item to prioritize.

Estimate the job cost

Estimate the cost of performing the work item. The details of how do to this are discussed in the Estimating effort recipe.

Estimate the business value

Whether you are considering the criticality of the work item or its usefulness of the work item, or both, estimate its business value. For this and the other estimates contributing to the cost of delay, we are using relative measures with a Fibonacci sequence with the higher values corresponding to greater business value. Work items of similar business value should have the same value here.

Estimate the project value

The project value is the value that the completion of the work item brings to the project, such as the completion of a technical work item or paying down technical debt.

Estimate the time criticality

Estimate the time criticality of the work item, with more urgent work items having a higher value.

Estimate the risk reduction or opportunity enablement value

Estimate either the reduction of project risk or the enablement of business opportunity since the approach of the previous to steps. Greater risk reduction or greater opportunity means higher value.

Compute the Cost of Delay (CoD)

Compute CoD as the sum of the business value, project value, time criticality, and risk reduction.

Compute the weighted shortest job first

Compute WSJF as the cost of delay divided by the job cost.

Group similar priority items into the iteration backlog

The backlog for each iteration should contain elements of the same priority, depending on the availability of resources to perform the work. If there is capacity left over after allocating all elements of the same or similar priority, add work items from the next lowest priority. Similarly, if the accumulated cost of the set of work items of the same priority exceeds capacity, then move some to the next iteration backlog.

Adjust work item priorities to account for iteration missions

Examine the work items for congruence with the mission of the iteration. If there is no congruence, then is there another iteration where the work item is more in line with the iteration purpose? If so, adjust the priority to match that of the more relevant iteration.

Adjust work item priorities to adjust for any needed specialized resources available

Are there specialized resources needed for the completion of a work item? This might be the availability of a Subject Matter Expert (SME), or the availability of computational or lab resources. Adjust the priority of work items to align with the availability of resources needed to accomplish the task.

Populate iteration backlogs with items of similar priority

Once the priorities have stabilized to account for all concerns, populate the iteration backlogs with the work items.

How it works

Prioritization is the ranking of elements on the basis of their desired sequencing. There are many means for prioritization with varying degrees of rigor. I prefer the WSJF approach because it takes into account most of the important aspects that should affect priority, resulting in a quantitative measure of the cost of delay divided by the size of the job.

Figure 1.27 shows a graph of WSJF isoclines. All curves show how the resulting value of WSJF changes as job size increases. Each separate curve represents a specific value for the cost of delay. You can see that the priority value diminishes rapidly as the size of the job grows. The practical effect of this is that higher-cost (i.e., higher-effort) tasks tend to be put off until later.

Just be aware that this is a bit problematic; since they require multiple iterations, there will be fewer iterations in which to schedule them:

Figure 1.27: WSJF iscoclines

While this method is recommended by the SAFe literature, in actual practice it must be modified so that you have congruence with the missions of the iterations. For example, it could happen that providing an encrypted message transfer has a high WSJF value while the creation of the base protocol stack is a lower value. Nevertheless, it makes no sense to work on the encryption design before you have a protocol in place over which the messages can be sent. Thus, you would likely raise the priority of the creation of the protocol stack and lower the priority of the encryption work to get “sensical sequencing.” Encryption math can be quite complex and if the encryption subject matter expert isn’t available for Iteration 6 but is available for Iteration 8, then it makes sense to adjust the priority of the encryption task to implement it when that expertise is available.

Example

Table 1.11 shows a worksheet that has a number of different kinds of work items, their previously estimated effort (job size), and the CoD terms. The spreadsheet sums up the terms to compute the Cost of Delay (CoD) column and then the WSJF shows the computed Weighted Shortest Job First.

The next column is the adjusted priority. This priority is generally the WSJF value but some of these are adjusted to move the work item into an appropriate iteration. The last column shows in which iteration a work item is planned to be resolved:

 

Work item type

 

 

Cost of delay terms

 

 

Priority

 

Epic

Work item use case

Work item user story

Spike or technical work item

User business value

Project value

Time criticality

RR | OE

CoD

Job size (user story points)

WSJF

Priority

Planned Iteration

 

 

 

Spike: Team availability

1

55

1

21

78

2

39.00

39.00

0

 

 

 

Spike: Aggressive schedule

1

1

34

34

70

3

23.33

23.33

0

 

 

 

Spike: Agile MBSE impact

1

34

21

13

69

3

23.00

23.00

0

Resist

Control resistance

Provide basic resistance

 

55

1

21

1

78

55

1.42

1.42

1

 

 

 

Spike: Motor response lag time

8

1

1

1

11

8

1.38

12.00

1

 

 

 

Spike: Robustness of main motor

34

1

1

34

70

5

14.00

14.00

1

Set up physical bike

Set up bike fit

Adjust seat height

 

13

1

13

13

40

3

13.33

13.33

1

Set up physical bike

Set up bike fit

Adjust seat reach

 

13

1

8

13

35

3

11.67

11.67

2

 

 

Calibrate power output

 

8

8

21

1

38

8

4.75

10.00

2

Emulate gearing

Emulate front and rear gearing

 

 

34

1

21

1

57

34

1.68

19.00

2

Emulate gearing

Emulate mechanical gearing

 

 

21

1

21

1

44

34

1.29

10.00

2

Emulate gearing

Emulate basic gearing

 

 

34

1

34

1

70

89

0.79

10.00

2

Set up physical bike

Manually adjust bike fit

 

 

34

1

21

1

57

13

4.38

4.38

3

Set up physical bike

Set up bike fit

Adjust handlebar height

 

8

1

1

3

13

3

4.33

4.33

3

Set up physical bike

Set up bike fit

Adjust handlebar reach

 

5

1

1

3

10

3

3.33

3.33

3

Monitor ride metrics

 

Monitor power

 

34

1

1

1

37

13

2.85

2.85

3

Monitor ride metrics

 

Monitor speed

 

21

1

1

1

24

5

4.80

4.80

3

Monitor ride metrics

 

Monitor distance

 

21

1

1

1

24

5

4.80

4.80

3

 

 

 

Spike: USB robustness

21

8

1

8

38

5

7.60

7.60

3

Monitor ride metrics

 

Monitor cadence

 

8

1

1

1

11

5

2.20

2.20

4

Communicate with apps

Communicate with low-power Bluetooth

 

 

55

1

8

1

65

34

1.91

1.91

4

Set up physical bike

Set up bike fit

Select crank length

 

2

1

1

2

6

5

1.20

1.20

4

Resist

Control resistance

Set resistance under rider control

 

13

1

5

1

20

21

0.95

1.00

4

Configure bike for rider

Connect personal data to app

 

 

13

1

1

1

16

21

0.76

1.00

4

Set up physical bike

Estimate bike fit with external parameters

Compute fit from professional fit data

 

3

1

1

1

6

1

6.00

0.50

5

Monitor ride metrics

 

Monitor incline

 

13

1

1

1

16

8

2.00

0.50

5

Communicate with apps

Communicate with ANT+

 

 

34

1

5

1

41

34

1.21

0.50

5

Communicate with apps

Communicate with ANT FEC

 

 

34

1

13

1

49

55

0.89

0.89

5

Set up physical bike

Estimate bike fit with external parameters

Load GURU bike fit data

 

5

1

1

2

9

13

0.69

0.69

5

Set up physical bike

Estimate bike fit with external parameters

Load trek bike fit data

 

5

1

1

2

9

13

0.69

0.69

5

Resist

Control resistance

ERG mode

 

21

1

1

1

24

55

0.44

0.30

5

 

Manage personal data

 

 

21

3

2

1

27

5

5.40

0.30

6

Set up physical bike

Predict bike fit with camera image

Access camera image

 

5

1

1

1

8

2

4.00

0.30

6

Set up physical bike

Predict bike fit with camera image

Retrieve road bike dimensions from camera image

 

8

1

1

1

11

5

2.20

0.30

6

Set up physical bike

Predict bike fit with camera image

Compute fit parameters from road bike dimensions

 

1

1

1

1

4

2

2.00

0.30

6

Resist

Control resistance

Set resistance under external control

 

21

1

5

1

28

39

0.72

0.30

6

Emulate gearing

Emulate DI2 gearing

 

 

13

1

5

1

20

55

0.36

0.30

6

Table 1.9: Prioritized work items