Sprint, the iteration, is the basic unit of development in Agile cSrum. Scrum puts emphasis on working product at the end of the iteration that is really done (see here for more on done) – something which is fully integrated and ready to be shipped. However, in my initial days of Scum adoption, whenever we started working on a new product-line, we never achieved what we planned for a sprint in some form – let alone something ready to be shipped. Sprint retrospectives revealed that at the start of a new product line or a major feature, the developers made a lot of assumptions on technical feasibility (like third-party APIs, hardware availability) which also affects how the software architecture is shaped. Mid-way of the sprint, we used to discover that some user-stories would be impossible and a few others would take a lot more time that we expected them to. The user-stories were valuable and useful – but did make a lot of assumptions on feasibility. The assumptions remained unverified during sprint planning resulting in a lot of disappointment for all the stakeholders. That led to the birth of feasibility sprint.

What is a Feasibility Sprint? 

A sprint which is designed to uncover the assumptions and lay the foundations for the sprints ahead with a clear understanding of what is possible and time it takes for something that is possible. The common understanding for this sprint was:

• Time boxed like any other sprint; usually a bit longer than the usual 2-week sprints. For complex product lines, even a 6-week long feasibility sprint is most often worth the time.
• “User” Stories revolve around testing complex assumptions in order to understand what is feasible technically in the prescribed eco-system and effort involved in making it feasible. Insist on demonstrable proof-of-concept even if it runs from the developer’s IDE.
• Acceptance criteria: The sprint is deemed to be “done” if each user story can be classified into one of these: (a) Possible to build (b) Not possible to build (c) Possible to build with workarounds (d) Partially possible.
• Sprint Review: The team “demos” the proof of concept and understands what is feasible and what is not.
• After-sprint: The Product Owner will have to assess the impact of the sprint on the user stories and backlog by: (a) Re-writing or splitting user stories (b) Re-prioritising the product backlog (c) Communicate to the stakeholders on the shape the product will take if there is considerable deviation in the product feature or if the timeline is way longer than expected.

Challenges 

Feasibility sprint is usually an afterthought as stakeholders are optimistic about their assumptions and timelines. Only after burning the fingers in a short sprint does one realize that an item of a sprint needed some feasibility study. Senior team members must have the experience and maturity to identify an item that cannot go into the regular sprint.

If you are not doing frequent Feasibility Sprints in your organization, it might be an indication that you are aiming only for things which you have complete clarity about and taking almost no risks.

Postscript

Feasibility sprint has a close resemblance to Sprint Zero – which is more to bootstrap a Sprint process for a new product.