Rootstrap Blog

Talking Points: Agile Inception

The primary goal of Rootstrap — Neon Roots’ Agile Inception Service, is to have a basic understanding of the proposed project and provide a general roadmap and NOT a blueprint. It is short… and rapid. Because the objective is to have something good enough so development can start.

agile inception

An Introduction

During the course of conducting many Rootstraps, Neon Roots’ agile inception workshop, we came into a realization that not all of our clients will be well oriented in Agile or the Scrum framework. As such is the case, we deemed it necessary to educate them knowing that one of the reasons for a project to fail is an uninitiated Product Owner or stakeholder representative.

We provide our clients with as much information, including reading materials like our PlaybookScrum/Agile Guide and Product Owner Primer, to augment their understanding of what we do and why we do things. Yet, despite these, we still come across Product Owners who misconceive that the output of an Agile Inception is a near perfect blueprint that is complete from head to toe, with projected development cost and delivery dates expected to be almost 100% accurate.

Our series of memorandums containing Talking Points, is yet another attempt to articulate and emphasize the underlying Agile principles we abide by and practice. We encourage our Teams to pound on these principles as early as project exploration and especially during Rootstrap in order to avoid misunderstanding and the usual expectation mismatch. Although these memos are intended for our teams, we think it’s important to share these memos to our existing and potential clients to convey our thought process.

We will be posting these memos in drips so that it would also be easier to digest and remember. Well at least that’s our goal.

First Memo in our series is about Requirements Elicitation and the Role of Wireframes.

One common trap an uninitiated client or Product Owner falls into — is trying to have and get everything right at the onset. From the set of features to colors and fonts. Yet time and again, changes are introduced midway or at a certain point in the development.

agile inception

Requirements Elicitation

•  Rootstrap is an Agile Inception workshop, NOT a full-blown SSAD.

•  Ask questions to elicit user stories and understand requirements. Try to avoid discussing specific solutions, they can come later.

•  Don’t try to come up with everything. Just enough so development can be started

•  Don’t over analyze requirements, just enough to get an understanding of what the PO needs. Further details will follow during development.

•  Don’t get stuck with a requirement due to your inability to come up with solutions – move on. Say you may need further research.

•  Basic understanding of solutions may become necessary only when proposing a general technical architecture. (Why iOS, phonegap, Android, native, cloud, etc. Even this should be flexible by the way)

•  Even when you can’t come up with a complete or extensive solution – make a decision. “It seems feasible” is good enough to avoid analysis paralysis.

•  Remember, Agile inception means you shouldn’t be bounded to the solution initially proposed when a better one comes along. Inspect, adapt, iterate…


•  During Agile Inception, it is advised that you try stay away from design (UI/UX) for as long as possible. Usually and more frequently, when discussion on design (UI/UX) starts, the tendency is to talk about solutions.

• Wireframes/Mock-ups are supposed to help you and the PO understand the requirements. Not a blueprint for what the App will become. (But this is NOT what usually happens.)

•  Always emphasize that wireframes are drafts, dynamic and should be open to changes (colors, shapes, etc.)

•  Remember, decisions are better made when you see a working product that you are able to visualize and experience. Concepts are good when used as guide. So ROADMAP instead of Blueprint. Roadmap has several possible routes to arrive at the same destination.

Note: It is important to always emphasize to the client these underlying guidelines when doing inception. It impacts deliverables — estimates, projections, design and features among others.

We’ll be continuing with our Talking Points series to help give you a better understanding of our process. Check our blog often for updates.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.