When we have some space in the delivery pipe and decide to feed it with a new feature that we have collectively agreed to prioritize, we need to start brainstorming about the potential solutions that could enable us to satisfy the top prioritized needs.
Probably, this will have started already while specifying the need, as people will start with solutions instead of needs. ;-) But we need to do some proper brainstorming to open our mind and not get stuck with the first solution that came to our mind. And make sure what is going to enter the delivery pipe is specified clearly.
Every need will be assigned to a "product owner", and when a feature candidate has been selected, this feature candidate will be assigned to a "product owner" AND a "tech owner". They are responsible to organize the solution discovery and inception process, that will go through the steps explained below.
This inception process is organized along the inception pipe, which a feature candidate enters after being selected among the list of Feature Requests on the wishlist board. (Prioritised feature requests are transferred to this pipe because issues which are submitted to the wishlist board in the firste step often have very different scopes; some of them will qualify as Papercuts and don´t need to follow the same thorough inception process or will be rejected).
That means listing all the possible solutions to answer the need. Those potential solutions are called "feature candidates". This is mostly a "product owner" job, but tech can also help in identifying feature candidates to meet the need.
For each potential solution, we evaluate the easiness level and value level, and map the feature candidates in a value/ease matrix. Having a tech perspective is important here as product people won't know how hard it is to implement feature candidate A or B. So the product owners needs to make sure they include the tech owner (or other devs) in that work.
This will help us choose the feature candidate that enables us to get enough value to meet the need, and that will request the least effort for that. Basically we aim to choose a feature candidate that adds the most value regarding the need (or enough value for the need to be met) at the lowest cost possible.
When the feature candidate has been fully incepted (i.e. all specifications are clear and well described, designs are ready, tech and product approval are confirmed), the product owner transfers the feature to the delivery pipe (and creates smaller stories if the original issue is more the size of an epic). When the delivery circle decides the feature is ready to be added to the pipe, they will transfer the issue it to the "dev ready" column, at the right level of priority.
This epic needs to encompass:
- reminder of the overaching unmet need (can add link to the need description and solution discovery session)
- why this feature would help us meet the need
- metrics that will enable us to check if it does
- who are the product and tech owners