This topic was initially approached in the post How do you define a PoC? , now the focus will turn to the results evaluation: what have we learned with it? Was it worthy the time invested with a critical feature? Have we enough information to start immediately an MVP?
We can state that a PoC is a learning opportunity, some authors also defend that normally a PoC starts during the Exploration phase.
Type of complexity evaluated during a PoC
Mainly we will be evaluating complexity at least in one of the two dimensions:
- Concept complexity or
- Technical complexity.
If the objective is to define a product or feature concept, we will be learning from Users or Customers feedback. We can engage since the PoC requirements phase with an user experience expert to have more structured interviews with a pre-selected cluster of key users.
If for any reason you don’t have UX resources and you start with requirements coming directly from the Product Owner, I recommend you, sprint by sprint, during the sprint review meeting, collect as much feedback as possible from this cluster of key users. Get prepared with a kind of test script, and a list of questions it could came to the Dev Team during the sprint implementation. Treat this PoC sprint reviews like a kind of premature User Acceptance Tests sessions, but as we are in an exploration environment, take all opportunities to validate your thoughts directly with the target users.
Those sessions are extremely important to guide us in aspects like User Experience (UX) or even Product architecture. We will see that maybe initial premises will fall down and new issues will popup.
Here we will be dealing with a more objective complexity, We know the challenge we want to reach. Technical PoCs are often related with implementation or optimization challenges.
The PoC evaluation, independently of his nature, should be supported by objective and measurable criteria.
For instance, in a conceptual PoC, we can always identify measurable criteria by comparison with the present process or tool supporting the process: time to finish a task, time to learn the execution of the task in the new system, criteria related with what we are affording or spending more or less with the particular feature we implemented.
The evaluation criteria for a technical PoC are easier to identify, in my point of view. If for example we are comparing technologies or platforms to implement a particular use case, we can always select technical criteria and compare them:
- Time to customize each platform;
- Available resources to do it, with this particular know how;
- Performance criteria;
- Infrastructure investment.
Stakeholders role during the PoC
Decide to do a PoC requires investment. We must have the buy in from our stakeholders to have the time and resources available during the PoC.
We should also make sure they understood scope and expected accomplishments by thr end of the PoC ( expectations management).
This is the role of the Agile team: explain (and ideally convince) Stakeholders to support those initiatives.
Moving forward after the PoC
In my point of view, the main goal for the development of a PoC is always accomplished if the team learns with and moves forward in the possession of more knowledge, less doubts and making better product decisions for the future.