Analysing Wants

We often find ourselves on the user end of the spectrum, despite the amount of production we’re engaged in – humans are primarily consumers, and then producers in today’s economy. Peeking into the user’s head for what they want is a desirable process that many businesses wish to carry out, in order to ultimately create the perfectly tailored product.

Ideally, there should be no excesses, and no shortfalls regarding this, as a great amount of resources are at stake during product development – potential losses in this environment may even result in your business vanishing overnight.

In modern parlance – particularly in the product development world, the QA (Quality Assurance) process is extremely crucial in determining product design and processes like troubleshooting, debugging and prototyping.

The QA process will also naturally incorporate product capabilities – what the product can, or cannot do – and this in turn is determined by what we call User Stories.

User Stories are all about determining what the User wants from the product. For example, if the user is examining an online shopping app in the process of development, then he/she may say:

“As a consumer, I want shopping cart functionality to easily purchase items online.”

“As a consumer, I want my payments to be secure and one click based.” (Obviously, to avoid the hassles of recurring card detail input)

Most User Stories are in this format:

As a [user role], I want to [goal], so I can [reason].

These also help define the user’s relationship with the product and the desired capabilities. However, the small, concise nature of the User Story should not fool you. Some stories are deceptively large in their scope, and the functionality cannot be tested in one single day, or one single iteration.

An iteration is a solution driven, time-bound process that has a set of goals to be achieved in a particular time-frame, pertinent to the product in the stages of development.

For example, say that you have an app – the consumer’s first concern may be that they want to log in. Now, the login process consists of them getting the empty fields for information input (Name, Date of Birth, email – etc.) so that they are incorporated into your app infrastructure for further service. The login itself may be automatic (the next time, they may not need to enter information) or otherwise. Storing the client’s information is yet another process, and recurring clients may also have other perks that need to show up on their profiles in the app. OTP generation for payment related matters, and secure gateways for the same involve another level of programming.

The point is: this deceptively simple act of logging in has a ton of other variables and testable factors. Thus, some user stories that are too large in scope are called ‘Epics’, which need to be broken down into other smaller stories, typically written on cards that have predetermined formats. The idea is to break them down into elements that can be tested in a single iteration.

When does a User Story come into Play?

There are three common times when stories will be worked on during an agile project:

You often create a stack of user stories during Inception as part of your requirements envisioning activities to identify the scope of your system.
During construction iterations you will identify new stories, split existing stories when you realize that they’re too large to be implemented in single iteration, reprioritize existing stories, or remove stories as per scope. The point is that your stories evolve over time just like other types of requirements models evolve. Furthermore, enhancement requests may be identified by your support staff during the production phase and then forwarded to a development team as they are working on an upcoming release. These enhancement requests are effectively new stories in a different format.
Sometimes new stories will be identified during the Transition phase, although this isn’t very common as the focus of release is on hardening the system and not on new functionality. But it does happen, and these stories would be prioritized and placed on the stack in priority order just as you normally would

Why User Stories?

User stories are part of the agile development model – a method the dictates the way IT projects and teams are managed. Agile development was proved to be extremely effective because of its focus on the individual customer, working software and constant adaptation to changing requirements.

Control and fixed planning takes a backseat here, as communication, synergy and dynamism is highly encouraged. We believe it to be a more potent approach toward project development, as it is more user friendly and less rigid than other approaches. Juggernaut’s client-first approach is very well suited for this method, and is true to our ideals in terms of engagement.

The result is often a product that is a result of close collaboration between the idea generator (in this case, you, the client) and IT development companies (like us) in tandem with the customer you wish to target.

User Stories also serve to bridge the gap between verbal requirements (what the user wants) and software compatibility (what can be carried out, implemented – technically).

This dynamic approach also provides many solutions to the same problem, mitigating problems with single-minded solutions. Negotiations between the client and the company manifesting their vision occur at every stage of product development – broken down into smaller user stories.

Lastly, the approach is also targeted, with architects, developers, designers etc. working on their specialized bits as per requirement, avoiding the jack-of-all-trades, one-size-fits all kind of thinking.

User Stories: Effectiveness, and Conclusion

For user stories to be effective and just right, we employ the use of flowcharts for clarity, process breakdown and a step-by-step approach to the solution. Debugging and troubleshooting can be employed at every stage by breaking down the epic story into constituents.

Another point to remember is that to generate proper user stories, you NEED to research the user as thoroughly as possible, so that you don’t have a vague/incorrect idea about what the consumer wants from the app. The entire process will remain moot in that case, and will be extremely counterproductive.

NextJuggernaut’s integration with the agile development model and User Story adoption dictates our commitment to serving you, the client, in the most comprehensive manner possible. In that vein, we invite you to experience our process for yourself and choose us to power your on-demand platform or extant idea – the results will be far superior, and far more satisfactory.