Tidied up Feature Risk tags

docs/estimating/Fixing-Scrum.md

@@ -29,11 +29,11 @@ Work in Scrum is done within periods of time called _Sprints_.  Each sprint ends
 
 > "The goal of this activity is to inspect and adapt the product being built... Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created." - Essential Scrum (p26), _Rubin_
 
-In Risk-First, we tend to call this validation step [Meeting Reality](/tags/Meeting-Reality):  you are creating a [feedback loop](/thinking/Cadence) in order to minimise risk.  What is the risk you are minimising?  Essentially, we are trying to reduce the risk of the developers _building the wrong thing_, which could be due to misunderstanding of requirements, or perfectionism, or because the piece of work was ill-conceived in the first place.  In Risk-First, the risk of building the wrong thing is called [Feature Risk](/tags/Feature-Risk).
+In Risk-First, we tend to call this validation step [Meeting Reality](/tags/Meeting-Reality):  you are creating a [feedback loop](/thinking/Cadence) in order to minimise risk.  What is the risk you are minimising?  Essentially, we are trying to reduce the risk of the developers _building the wrong thing_, which could be due to misunderstanding of requirements, or perfectionism, or because the piece of work was ill-conceived in the first place.  In Risk-First, the risk of building the wrong thing is called [Feature Fit Risk](/tags/Feature-Fit-Risk).
 
-![Feature Risk mitigated by Meeting Reality](/img/generated/estimating/scrum/scrum1.svg)
+![Feature Fit Risk mitigated by Meeting Reality](/img/generated/estimating/scrum/scrum1.svg)
 
-The above diagram demonstrates us mitigating [Feature Risk](/tags/Feature-Risk) (the risk of not building the right software for our clients) by organising a Sprint Review.  But there is a downside to a Sprint Review:  _it takes time_.
+The above diagram demonstrates us mitigating [Feature Fit Risk](/tags/Feature-Fit-Risk) (the risk of not building the right software for our clients) by organising a Sprint Review.  But there is a downside to a Sprint Review:  _it takes time_.
 
 ![Schedule Risk for Stakeholders](/img/generated/estimating/scrum/scrum2.svg)
 
@@ -121,7 +121,7 @@ How can we, as software developers, minimise the chance of building the wrong th
 
 ![Scrum](/img/generated/estimating/scrum/scrum4.svg)
 
-Look above at the diagram what Scrum is trying to do to mitigate [Feature Risk](/tags/Feature-Risk):
+Look above at the diagram, showing how Scrum is trying to mitigate [Feature Fit Risk](/tags/Feature-Fit-Risk):
 
 - We [Meet Reality](/tags/Meeting-Reality) to ensure we've got a feedback loop.
 - We **time-box** to avoid wasting stake-holders' time (Schedule Risk).

docs/estimating/Kitchen-Cabinet.md

@@ -122,11 +122,11 @@ This is important:  the point at which you present your estimate is the point of
 
 ![Accepting an estimate](/img/generated/estimating/accept_estimate.svg)
 
-The diagram above is an example of this.   A supplier is bidding for a contract with a client.  The client has functionality they want build (or [Feature Risk](/tags/Feature-Risk) as we call it on Risk-First).  The supplier needs money to keep their business going ([Funding Risk](/tags/Funding-Risk) on this diagram).  
+The diagram above is an example of this.   A supplier is bidding for a contract with a client.  The client has functionality they want build (or [Feature Fit Risk](/tags/Feature-Fit-Risk) as we call it on Risk-First).  The supplier needs money to keep their business going ([Funding Risk](/tags/Funding-Risk) on this diagram).  
 
-If the estimate is accepted, the supplier's [Funding Risk](/tags/Funding-Risk) is transferred to the client (the requester of the estimate).  Conversely, the trade is that the client's [Feature Risk](/tags/Feature-Risk) is transferred to the supplier.
+If the estimate is accepted, the supplier's [Funding Risk](/tags/Funding-Risk) is transferred to the client (the requester of the estimate).  Conversely, the trade is that the client's [Feature Fit Risk](/tags/Feature-Fit-Risk) is transferred to the supplier.
 
-If the supplier is short on opportunities or funds, there is a tendency to under-estimate.  That's because the [Feature Risk](/tags/Feature-Risk) is a problem for the supplier _in the future_, whereas their [Funding Risk](/tags/Funding-Risk) is a problem _right now_.  
+If the supplier is short on opportunities or funds, there is a tendency to under-estimate.  That's because the [Feature Fit Risk](/tags/Feature-Fit-Risk) is a problem for the supplier _in the future_, whereas their [Funding Risk](/tags/Funding-Risk) is a problem _right now_.  
 
 You can often see suppliers under-bid on projects because of this future discounting, which we discussed before in [Evaluating Risk](/thinking/Evaluating-Risk#discounting).  
 
@@ -144,9 +144,9 @@ This means that clients often keep projects running for far longer than they sho
 
 There is an alternative to too-early or too-late risk.  You can always choose to be _on time_.  This is definitely a choice: Just like a student can always hand _something_ in on assignment day (even if it's just a title scrawled on a piece of paper), you can always hand in whatever work you have.  
 
-Then, instead of worrying about [Scarcity Risks](/risks/(/tags/Scarcity-Risk), you are letting [Feature Risk](/tags/Feature-Risk) vary to take up the slack.
+Then, instead of worrying about [Scarcity Risks](/risks/(/tags/Scarcity-Risk), you are letting [Feature Fit Risk](/tags/Feature-Risk) vary to take up the slack.
 
-So far, we've seen two kinds of estimate:  [Fill-The-Bucket](Fill-The-Bucket) and [Kitchen-Cabinet](Kitchen-Cabinet).  Now, it's time to review a third - estimating [Journey Style](Journeys), and looking at how we can minimise [Feature Risk](/tags/Feature-Risk) within an available budget.
+So far, we've seen two kinds of estimate:  [Fill-The-Bucket](Fill-The-Bucket) and [Kitchen-Cabinet](Kitchen-Cabinet).  Now, it's time to review a third - estimating [Journey Style](Journeys), and looking at how we can minimise [Feature Fit Risk](/tags/Feature-Risk) within an available budget.
 
 
 

docs/estimating/Risk-First-Analysis.md

@@ -29,7 +29,7 @@ The previous article, [Fixing Scrum](Fixing-Scrum), examined Scrum's idea of "Sp
 
 ![Scrum: Consequences Of Time-Boxing](/img/generated/estimating/planner/scrum-consequences.svg)
 
-The diagram above shows this behaviour in the form of a [Risk-First Diagram](/thinking/Risk-First-Diagrams).  Put briefly:  _risks_ ([Schedule Risk](/tags/Schedule-Risk), [Feature Risk](/tags/Feature-Risk)) are addressed by actions such as "Development", "Review" or "Planning Poker".  
+The diagram above shows this behaviour in the form of a [Risk-First Diagram](/thinking/Risk-First-Diagrams).  Put briefly:  _risks_ ([Schedule Risk](/tags/Schedule-Risk), [Feature Fit Risk](/tags/Feature-Fit-Risk)) are addressed by actions such as "Development", "Review" or "Planning Poker".  
 
 If you're new to [Risk-First](https://www.riskfirst.org) then it's probably worth explaining at this point that one of the purposes of this project is to enumerate the different types of risk you could face running a software project.  You can begin to learn about them all [here](/risks/Start).  Suffice to say, we have icons to represent each of these kinds of risks, and the rest of this article will introduce some of them to you in passing.
 
@@ -103,9 +103,9 @@ So, this diagram encapsulates the reason why we might fix the rendering bug:  it
 
 Let's move on to task 2, the **Search Function**, as shown in the above diagram.
 
-As with the **Rendering Bug**, above, we lose something:  [Feature Risk](/tags/Feature-Risk), which is the risk (to us) that the features our product is supplying don't meet the client's (or the market's) requirements.  Writing code is all about identifying and removing [Feature Risk](/tags/Feature-Risk), and building products that fit the needs of their users.
+As with the **Rendering Bug**, above, we lose something:  [Feature Fit Risk](/tags/Feature-Fit-Risk), which is the risk (to us) that the features our product is supplying don't meet the client's (or the market's) requirements.  Writing code is all about identifying and removing [Feature Fit Risk](/tags/Feature-Fit-Risk), and building products that fit the needs of their users.
 
-So as in the Rendering Bug example, we can show [Feature Risk](/tags/Feature-Risk) being eliminated by showing it on the left with a strike-out line.   However, it's been established during analysis that the way to implement this feature is to introduce [ElasticSearch](https://www.elastic.co), a third-party piece of software.  This in itself is an [Attendant Risk](/tags/Attendant-Risk) of taking that action:  
+So as in the Rendering Bug example, we can show [Feature Fit Risk](/tags/Feature-Fit-Risk) being eliminated by showing it on the left with a strike-out line.   However, it's been established during analysis that the way to implement this feature is to introduce [ElasticSearch](https://www.elastic.co), a third-party piece of software.  This in itself is an [Attendant Risk](/tags/Attendant-Risk) of taking that action:  
 
 - Are we going to find that easy to deploy and maintain?  
 - What impact will this have on hosting charges?  

docs/estimating/Stop-Estimating-Start-Navigating.md

@@ -106,7 +106,7 @@ What does that mean?
 
 The problem is that estimation only addresses a single risk:  runway risk/time resource.  It says nothing about other risks that you might bump into.
 
-Why is all my code in the bin?  I guess either it was badly written (which, probably it isn't, given that it's probably not objectively worse than the 10% that is in production) or, more likely, it didn't address _Feature RIsk_ properly, or, it was useful, but people didn't find out about how amazing it was.  Or, it was built to work on top of X, but then X was decomissioned (Dependency Risk) or, the budget was cut from the department and there was no funding (Dependency Risk... but maybe caused by Feature RIsk)?
+Why is all my code in the bin?  I guess either it was badly written (which, probably it isn't, given that it's probably not objectively worse than the 10% that is in production) or, more likely, it didn't address [Feature Fit Risk](/tags/Feature-Fit-Risk) properly, or, it was useful, but people didn't find out about how amazing it was.  Or, it was built to work on top of X, but then X was decommissioned (Dependency Risk) or, the budget was cut from the department and there was no funding (Dependency Risk... but maybe caused by Feature Fit Risk)?
 
 No estimates says forget about trying to get the numbers right, because you can't.  What's better than that?  Let's try and focus on reducing that 90% of waste by thinking about _risks other than time_.
 

docs/practices/Deployment-And-Operations/Redundancy.md

@@ -14,8 +14,6 @@ practice:
    - "Resilience"
    - "Stockpiling"
   mitigates:
-   - tag: Feature Risk
-     reason: "Ensures system availability and reliability in case of component failure."
    - tag: Reliability Risk
      reason: "Minimizes operational disruptions by providing backup components."
    - tag: Security Risk

docs/practices/Development-And-Coding/Coding.md

@@ -13,7 +13,7 @@ practice:
    - "Development"
    - "Software Engineering"
   mitigates:
-   - tag: Feature Risk
+   - tag: Feature Fit Risk
      reason: "Build or improve some features which our clients will find useful."
    - tag: Process Risk
      reason: Problems and edge cases with software processes can be fixed by adding code.

docs/practices/External-Relations/Fundraising.md

@@ -18,7 +18,7 @@ practice:
      reason: "Provides necessary financial resources to support the startup’s operations and growth."
    - tag: Market Risk
      reason: "Allows the startup to invest in market research and customer acquisition."
-   - tag: Feature Risk
+   - tag: Feature Fit Risk
      reason: "Enables the startup to fund product development and innovation."
   attendant:
    - tag: Agency Risk

docs/presentations/HowToWin/index.md

@@ -450,7 +450,7 @@ hide_table_of_contents: true
             <div class="slide-notes">
                       <p>So, the payoff, for doing Fixed Price Contract is that your business is going to make money - it’s funding risks will be reduced.</p>
 
-      <p>But, for the client, the great thing about a Fixed Price Contract is that they know how much the project will cost.  So, you’ve taken on their funding risk.  And of course, you’ve taken on their Feature Risk - you have to provide the Features of the software that this client needs.</p>
+      <p>But, for the client, the great thing about a Fixed Price Contract is that they know how much the project will cost.  So, you’ve taken on their funding risk.  And of course, you’ve taken on their Feature Risks - you have to provide the Features of the software that this client needs.</p>
 
       <p>So in order to make accurate estimates, and win these bets, it’s all about having a good internal model of the development process, and how long things take.</p>
 

docs/risks/Complexity-Risk/Complexity-Analogies.md

@@ -38,11 +38,11 @@ The most common way we talk about [Complexity Risk](/tags/Complexity-Risk) in so
 
 > "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." - [Ward Cunningham, 1992, _Wikipedia, Technical Debt_](https://en.wikipedia.org/wiki/Technical_debt)
 
-Building a low-complexity first-time solution is often a waste:  in the first version, we're usually interested in reducing [Feature Risk](/tags/Feature-Risk) as fast as possible. That is, putting working software in front of users to get [feedback](/thinking/Meeting-Reality).  We would rather carry [Complexity Risk](/tags/Complexity-Risk) than take on more [Schedule Risk](/tags/Schedule-Risk).
+Building a low-complexity first-time solution is often a waste:  in the first version, we're usually interested in reducing [Feature Fit Risk](/tags/Feature-Fit-Risk) as fast as possible. That is, putting working software in front of users to get [feedback](/thinking/Meeting-Reality).  We would rather carry [Complexity Risk](/tags/Complexity-Risk) than take on more [Schedule Risk](/tags/Schedule-Risk).
 
-So a quick-and-dirty, over-complex implementation mitigates the same [Feature Risk](/tags/Feature-Risk) and allows you to [Meet Reality](/thinking/Meeting-Reality) faster.  
+So a quick-and-dirty, over-complex implementation mitigates the same [Feature  Fit Risk](/tags/Feature-Fit-Risk) and allows you to [Meet Reality](/thinking/Meeting-Reality) faster.  
 
-But having mitigated the [Feature Risk](/tags/Feature-Risk) this way, you are likely exposed to a higher level of [Complexity Risk](/tags/Complexity-Risk) than would be desirable.  This "carries forward" and means that in the future, you're going to be slower.  As in the case of a real debt, "servicing" the debt incurs a steady, regular cost.
+But having mitigated the [Feature Fit Risk](/tags/Feature-Fit-Risk) this way, you are likely exposed to a higher level of [Complexity Risk](/tags/Complexity-Risk) than would be desirable.  This "carries forward" and means that in the future, you're going to be slower.  As in the case of a real debt, "servicing" the debt incurs a steady, regular cost.
 
 ### Kitchen Analogy
 
@@ -67,7 +67,7 @@ In Brooks' essay "No Silver Bullet - Essence and Accident in Software Engineerin
 
 The problem with this definition is that we are accepting features of our software as _essential_.  
 
-Applying Risk-First, if you want to mitigate some [Feature Risk](/tags/Feature-Risk) then you have to pick up [Complexity Risk](/tags/Complexity-Risk) as a result.  But, that's a _choice you get to make_.  
+Applying Risk-First, if you want to mitigate some [Feature Fit Risk](/tags/Feature-Fit-Risk) then you have to pick up [Complexity Risk](/tags/Complexity-Risk) as a result.  But, that's a _choice you get to make_.  
 
 ![Mitigating Feature Risk](/img/generated/risks/complexity/feature-creep.svg)
 

docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md

@@ -26,7 +26,7 @@ Process Risk intersects with several other types of risk we've covered so far:
 - [Agency Risk](/tags/Agency-Risk): Processes have their own agency - they often involve decision making (a loan application or passport renewal).
 - [Reliability Risk](tags/Reliability-Risk): Processes can fail for various reasons (a payment process for example).
 - [Communication Risk](/tags/Communication-Risk): You need to communicate intent to the process, and have it report back its status (think of buying something on the Internet, and the delivery company communicating where the parcel is in transit).
-- [Feature Risks](/tags/Feature-Risk): A Process should be supplying some useful _features_ to you in order for you to use it.  Is it fit for purpose? (An example might be starting to fill out a form but then realising you're filling out the wrong form).
+- [Feature Fit Risk](/tags/Feature-Fit-Risk): A Process should be supplying some useful _features_ to you in order for you to use it.  Is it fit for purpose? (An example might be starting to fill out a form but then realising you're filling out the wrong form).
 
 So clearly there is overlap here with other types of risk we've looked at:  a good process should be reliable, available (i.e. not scarce), transparent in its communications and obedient to our wishes.  In fact, Process Risk really should be thought of as just a wrapper for other things.  Nevertheless, it's a useful pattern to talk about as it comes up repeatedly.