|
| 1 | +--- |
| 2 | +name: Feature ticket |
| 3 | +about: A full description of a new feature, or part of a feature, that we wish to develop |
| 4 | +title: '' |
| 5 | +labels: "feature" |
| 6 | +assignees: '' |
| 7 | +--- |
| 8 | + |
| 9 | +_Ensure the ticket title clearly communicates what this feature ticket makes possible_ |
| 10 | + |
| 11 | +_Add the **milestone** and **project** of the Major Release this feature is part of i.e. Oregon Trail_ |
| 12 | + |
| 13 | +_Add a **label** for the feature that this ticket is part of i.e. Data Sourcing_ |
| 14 | + |
| 15 | +# Feature Overview |
| 16 | +A simple overview that describes what this feature (or sub feature) needs to do and why it's valuable. |
| 17 | +This should be brief, understandable by anyone in the business and use the format: |
| 18 | + |
| 19 | +As a (who - the type of user/actor the feature serves) |
| 20 | + |
| 21 | +I want (what - the action to be performed / made possible) |
| 22 | + |
| 23 | +So that (why - the goal/result/value it achieves to the user/actor or the business) |
| 24 | + |
| 25 | +# Tasks |
| 26 | +A checklist of the tasks that are needed to develop the feature and meet the accceptance criteria and feature test scenarios. Ideally, tasks would reflect the pull requests likely to be created when developing the feature. |
| 27 | + |
| 28 | +- [ ] |
| 29 | +- [ ] |
| 30 | +- [ ] |
| 31 | + |
| 32 | +# Product Owner |
| 33 | +The name of the person in the Product team that is responsible for this feature. This will be the go-to person for the engineer working on this ticket for any questions / clarifications, to get feedback on work in progress and who will ultimately accept the feature ticket as 'done'. |
| 34 | + |
| 35 | +_**Assign** the named product owner to the ticket_ |
| 36 | + |
| 37 | +# Acceptance Criteria |
| 38 | +A list of criteria (aim for 3!) that have to be met for this feature to be accepted as 'done' by the product owner. Acceptance criteria should be simple, single sentence, statements written from the perspective of the work already having been done. Each statement should be able to be objectively determined to be true or false. For example: |
| 39 | + |
| 40 | +- It is possible to |
| 41 | +- It is possible to |
| 42 | +- Vega does |
| 43 | +- Vega does |
| 44 | + |
| 45 | +Acceptance Criteria and Feature Test Scenarios can, in some cases, be closely related. If acceptance criteria become fully covered by feature test scenarios they can be removed leaving on acceptance criteria that can't be directly or fully proven with tests. |
| 46 | + |
| 47 | +# Test Scenarios |
| 48 | +Detailed scenarios (1-3!) that can be executed as feature tests to verify that the feature has been implemented as expected. We use the follow format: |
| 49 | + |
| 50 | +GIVEN (setup/context) |
| 51 | + |
| 52 | +WHEN (action) |
| 53 | + |
| 54 | +THEN (assertion) |
| 55 | + |
| 56 | +For example... |
| 57 | + |
| 58 | +```gherkin |
| 59 | + Feature: Account Holder withdraws cash |
| 60 | + Scenario: Account has sufficient funds |
| 61 | + Given the account balance is $100 |
| 62 | + And the card is valid |
| 63 | + And the machine contains enough money |
| 64 | + When the Account Holder requests $20 |
| 65 | + Then the ATM should dispense $20 |
| 66 | + And the account balance should be $80 |
| 67 | + And the card should be returned |
| 68 | +``` |
| 69 | + |
| 70 | +See https://github.com/vegaprotocol/vega/tree/develop/integration/ for more format information and examples. |
| 71 | + |
| 72 | +_TBC whether these should be separate files - will come back to this_ |
| 73 | + |
| 74 | +# Impacted Systems / Engines |
| 75 | +A list of the engines that we believe will be impacted by the development of this feature. _Delete as appropriate_ |
| 76 | + |
| 77 | +- Core - banking |
| 78 | +- Core - collateral |
| 79 | +- Core - execution |
| 80 | +- Core - fee |
| 81 | +- Core - governance |
| 82 | +- Core - liquidity |
| 83 | +- Core - oracles |
| 84 | +- Core - positions |
| 85 | +- Core - risk |
| 86 | +- Core - settlement |
| 87 | +- Core - monitor |
| 88 | +- API |
| 89 | +- Wallet |
| 90 | +- Liquidity bot |
| 91 | +- Trader bot |
| 92 | + |
| 93 | +# API Calls |
| 94 | +A list of the API calls that are needed for this feature, written in an implementation-agnostic format i.e. "Get a list of widgets, categorised by X", rather than "GET /widgets?category=X": |
| 95 | + |
| 96 | +- Get a list of widgets, categorised by X |
| 97 | +- Get x |
| 98 | +- Get y |
| 99 | + |
| 100 | +# Dependencies |
| 101 | +Links to the tickets that represent work that this feature ticket is dependent on to be able to start / finish development. This could be another feature ticket, an important refactoring task, some infrastructure work etc. For each dependency please add a categorisation of the type of dependency (hard or soft) and whether it is internal or external to the team. |
| 102 | + |
| 103 | +- #Link to ticket + Dependency ticket name | hard/soft | internal/external |
| 104 | +- #Link to ticket + Dependency ticket name | hard/soft | internal/external |
| 105 | +- #Link to ticket + Dependency ticket name | hard/soft | internal/external |
| 106 | + |
| 107 | +_Add a **label(s)** to represent the types of dependency this feature ticket has (soft_internal_dependency, soft_external_dependency, hard_internal_dependency, hard_external_dependency)_ |
| 108 | + |
| 109 | +# Additional Details (optional) |
| 110 | +Any additional information that provides context or gives information that will help us develop the feature. |
| 111 | + |
| 112 | +Feature spec: |
| 113 | + |
| 114 | +# Examples (optional) |
| 115 | +Code snippets from the spec for reference |
0 commit comments