Sprint Questions

Answering the Sprint Questions is similar to the long term goal. During the workshops, the team agreed on three focus questions or HMWs, which need to be worked on primarily. If those all find positive responses, the project is a full success. Most of the time, it's a mix of positive and negative, but with a clear opportunity for improvement.

Your task is to analyze the existing feedback and respond to the sprint questions clearly and succinctly. Your writing should give the client confidence that their team made good decisions during the workshop, and if not, that it's possible to make better decisions now and implement the right thing. It's very important that the answers to the sprint questions sound honest but encouraging.

Below are a few examples from the Fluence Project.

1. Can we avoid building a too complex system with many moving parts - and that it falls under its complexity?

   Yes.

   Users responded positively that it was simple and easy to use. Fluence is relatively complex but we compressed it into a much more succinct platform. The flow needs a few modifications and if we bring the service hub into the main interface and allow for back-and-forth interaction it can become much easier. More explanations will also help clarify how publishing/deployment works.

2. Can we move fast enough to distinguish ourselves from the competition?

   Likely.

   Users we spoke to in the blockchain space expressed there was a real need for this service. Response from users indicated that this was new to them, fulfilled a need, and in Fllek's case, they could see using it for their own development, as well as providing it to their users. The broad public is most interested in lower prices and better accessibility. If we can make clear the benefits of the decentralised system we can grab users attention and make Fluence more appealing. Larger organisations who prefer a decentralised system will likely pay for the service.

3. Can we onboard developers so they get excited about building on and for Fluence?

   If we fix the flow.

   Most developers liked the platform and would play with it, as long as it fits their mental model and offers more handholding with explainers and examples. The response to the concept of being able to monetize their own packages was well-liked and could be a major pull for users to the platform.

Back to Skill Tree

Workflow