Is The Confirmation in the 3Cs Of User Stories Making The Implementation Team Over Dependent?

Writing requirements as user stories is the most common and accepted form of documenting requirements in an Agile project. Moreover, product backlogs are made up of requirements written as user stories most of the time. User stories are considered to be simple to create, clear and concise and easily understood, and considered as convenient to update and maintain. 

User stories are written following a specific format, making it universally acceptable across the software industry. User stories follow the 3C’s format described below and focus on the business value each story provides to the user. Also, to know more, read about user stories examples. 

3C’s of user stories

1. Card
   The first C, ‘Card’ simply means that the user story must be small enough so that the content can fit on a small business card size board / paper. The user story takes the following format.

                                                                  As a [user | role | persona]

                                                               I must be able to [functionality]

                                                             So that I get [benefit | business value]

As best practice, we try to generalize by writing the requirement as required by a user group or role. For this it is imperative that ‘user research’ is done to capture the actual behaviours, opinions and attitudes of the users and be documented as ‘user persona’ documentation.

The functionality is documented with the keyword ‘must’ which stresses the fact that this is the exact feature required by the user. Some document the functionality with keywords such as ‘will’, ‘shall’, ‘would’, ‘should’ etc which actually leaves a bit of uncertainty and must be avoided at all times.

When documenting the benefit or the business value it is always good to keep in mind the ROI, cost saving, efficiency etc expected from the feature described.

The user story as we can see is a combination of ‘who’, ‘what’ and ‘why’ which together gives out a meaningful story. The user story defines functionality from a business perspective and does not define how the problem shall be solved.

• Conversation
  It is said to define a user story with enough detail to start development and less information to arouse discussion. Conversation must happen between the user and the implementation team as well as between the members of the implementation team and must be aimed at digging deep into the unstated and implied requirements of the customer. A good conversation would surely help unearth the creative side of the implementation team and whatever is unearthed, relevant or irrelevant must be listed down as additional information on the card.
• Confirmation
  Now we come to the most controversial component of the 3C’s – Confirmation. It is all about writing acceptance criteria. This is the section where the team or business analyst in most cases, is expected to detail out the business and validation rules, exact specification of the requirement, and sometimes even the step by step description of how to realize a certain requirement. The team may even write examples of particular scenarios if it involves complex processing and calculation. Teams are still fighting to keep the acceptance criteria as detailed as possible to that of a traditional detailed requirements specification and sometimes even maintain checklists of possible aspects to look for in defining requirements.

A user story and its possible acceptance criteria can be as below.
As a backpacker I must be able to search for rest houses so that I can identify a suitable place for my stay.
Acceptance Criteria:
Search for rest house by location, price range, facilities, cuisine, surroundings, rating

• Customize search as required
• Compare rest houses
• All key information to be available at one glance

But writing acceptance criteria in detail like this is never a good idea. There is no such thing as a complete or exact specification. A user expectation may not be defined in exact detail or accuracy all the time. Space must be kept for the team to have a good conversation to uncover hidden aspects about the requirements. As we can see from the above example itself we are unable to confidently say that we’ve covered the requirement to its entirety. For example, ‘what are the key information to be displayed and be available as a single view?’.

With this approach, the development team is never involved in story definition. They end up being spoon-fed, take the criteria one by one and implement as is. The main reason being they being able to blame the poor business analyst for not detailing the requirements adequately. It should ideally be a case where the requirements and the entire organizational change is driven by the business analyst and to have him involved collaborating and communicating identifying the change required to meet the customer needs throughout the life of the project.

Unleash your potential with PRINCE2 Foundation Certification - the ultimate key to project management success!

So, what is a better approach?

As explained before, the user story is about striking a conversation. Keep the story simple and short stressing on the expected behaviour and impact. These can be written as ‘Conditions of Satisfaction’. For example, ‘The backpacker can enjoy a nights stay after a tedious day at a budget hotel at a convenient location’.

Now, the team as a whole will be focused on solving the ‘problem defined’ by having a more user centric conversation. More user research will be done to identify solutions to address the user needs and in determining new ways of delivering more value. Discussion may take longer but ultimately, the team shall produce winning solutions that are geared to solving the real problem at hand.

So, it is up to you now to use your user stories wisely. ☺