Activity 1 | Choose One Thing |
Discuss priorities with stakeholders by presenting them with an extreme choice: if you only get one thing, what will it be? This activity can help stakeholders make decisions when facing difficult trade-offs.
Clearly communicates, this is more important than that.
Starts a conversation about why a certain choice was made and what would need to change for stakeholders to change their mind.
Makes it obvious when stakeholders disagree.
All stakeholders
List of alternatives, such as quality attributes, or other difficult trade-offs, such as cost, schedule, and features.
Explain the rules of the game. Stakeholders may choose only one of the presented options. Remind participants that this does not mean you will do only one thing, but instead the point is to have tough conversations early to avoid trouble down the road.
Present a set of options to stakeholders. Discuss what each option means and make sure everyone understands the options.
Force stakeholders to pick one option. All stakeholders should agree that this is the most important thing. In this activity we want consensus.
Briefly discuss why the option was selected. This discussion is often more important than the option picked.
Pick another set of architecturally significant requirements that are in tension with one another and play again.
Play this game before things get too difficult. This conversation is easier when it’s hypothetical than when it’s real.
Quality attributes that are in tension with one another should be pitted against one another.
Use this activity to prioritize influential functional requirements.
This technique works well as an informal conversation to help get better understanding of stakeholders’ true need.
Here are a few scenarios one team posed to some stakeholders and how things played out when stakeholders were asked to choose one thing:
Matchup | Stakeholder’s Choice |
---|---|
Faster performance or greater accuracy | Faster performance, assuming accuracy met a required minimum threshold. |
Cost vs. time-to-market | Time-to-market; stakeholders were willing to accept greater technical debt to get required features by a specific date. |
Usability vs. security | Security; this was the number one quality attribute and surprisingly beat several other important quality attributes. |
Availability vs. cost | Availability; achieving high availability on this particular system required potentially expensive redundancy for which stakeholders would willingly pay (up to a point) if required. |
Instead of pitting one alternative against another, use trade-off sliders to let stakeholders make multiple comparisons. To use this activity, identify 3--5 related alternatives. Each item can receive a number 1 -- N, where N is the number of items in the list. No two items can have the same number. This activity is often presented visually using sliders.
52.14.77.134