How to break down the requirements for an Agile Project Management

If the customer is the king, then agile is the method to keep the king-subject relationship alive & growing!

Agile is a serious buzzword used by many!

In essence, it is a modern project management system with an iterative & incremental approach to deliver business requirements throughout a project lifecycle. Constant & maximum value delivering is another prime objective of agile.

Image credit: medium.com

So, the prime principles of agile project management are:

• You need to break the requirements of the project into small pieces
• Prioritize the requirements as per the level of importance
• Agile project management reinforces the collaborative working environment with the customers
• The agile projects reflect, grow, and adjust regularly as per customer requirements
• Planning & execution are integral parts of agile project management

Knowing the customer requirements and fulfilling those is the heart line in an agile project management system where documentation is the most critical part.

The Agile Project Management Process

The agile project management process includes the following phases:

Breaking Down the Requirements for an Agile Project Management Process

The traditional process of compiling the requirement includes creating an SRS (Software Requirement Specification) or SoW(Scope of Work) document which comprises of all the aspects of the software within one single document. All these aspects are features to be implemented, functional requirements, design constraints, performance expectations, security, etc.

The software requirement document takes a considerable time for compilation and corrections. Doing so would delay the time to market for the product as this method is iterative in terms of writing, revisiting, and correcting. Further, this is a comprehensive document where the readers may lose the essence while going through it. 

This approach has gradually lost its popularity and a new approach is on the verge of replacing it with the changing market needs and competition amongst different providers. Yes...! We are talking about documenting the requirements ‘The Agile way’, in the form of themes, epics, and user stories. There are several benefits to this process:

1. The primary focus of an agile project management document is to emphasize user stories; which includes who are going to use it and how they are going to use it.
2. The agile project management enables you to go live early in the market, as one can release the application after implementing basic primary features having the highest priority to the users. This can be done iteratively multiple times depending on featured priorities. Keeping the users engaged with the features they get exposed to, as they keep seeing some progress or some cool exciting features on a timely basis!
3. This approach encourages feedback from the end-users and implementing further features based on the users’ interest. This, in turn, provides an upper edge in the competitive market with continuously changing user needs.
4. The agile project management provides simplicity in documenting the requirement which is easy to understand as well as an implement for the development team.
   
   

Analyzing the advantages of the agile project management approach, we are explaining the starting point:

The business entities, who are building the software, are called as product owners because they know what the end-users want from the products. The product owners comply with the requirements in form of the user stories which are constructive narratives. Breaking down requirements can be consolidated in the following steps:

Tips to break down the requirement Agile way: 

1. First and foremost, put yourself into the user’s shoes while defining the user stories. Consider that you are a user and you want something to be accomplished. Now, what you need to do is define what your expectations are, as a user. Try to jot it down in the form user story. The feature you are defining should be valuable for the end-user. 

2. Don’t get confused with Theme, Epic, and User Stories while breaking down the agile requirements. The primary goal should be to able to break down the requirements in the form of a user story as small as you can so that each user story can be as per the INVEST mnemonic.

3. While writing user stories think of three components primarily as shown below. Say I want to enable a user to buy a product on an e-commerce platform.
   
   

Once the above step is done, raise a question again. Can it further be broken down? If yes, do so. And ask at the end of each user story.

A question may arise how can we know that the user story can be further broken down or not? Let us see.

What are the prerequisites for a user to purchase a product?

1. View the product and its details
2. Select the product and add that to cart
3. Checkout and pay for the product (here, there arises one more question, where to ship the product? And a new user story emerges)

Now, let us try to further break this down. Try to think all possible scenarios so that I can satisfy the above user story.

Card:

• As a shopper/buyer

     I should see the list of products

     So that I can select products to purchase.

Conversation:

You can provide a sketch, wireframe, mockup or design to display how the screen would look like(visualization).

     Confirmation or Acceptance Criteria (checklist):

• • User should be able to see the list of all products
  • User should be able to see the product thumbnail, product name, product price, rating, and reviews. (whatever the requirement is)
  • Clicking on the thumbnail should show me the enlarged image.
  • Clicking on the product info should take me to the product detail page.
  • There should be an option to add the product to the cart.
  • There should be an option to add product in the Wishlist.

• As a shopper/buyer

     I should be able to view the details of a product

     So that I can know more about it.

Conversation:

You can provide a sketch, wireframe, mockup or design to display how the      screen would look like(visualization).

     Confirmation/Acceptance Criteria:

• • On clicking/tapping on the product in the product listing screen, this screen should appear.
  • User should be able to see the product name, product pictures, product actual price, product discounted price, delivery check based on the pin code, ratings, reviews, etc., (as per the need)
  • User should be able to swipe through the product pictures to see all the images. (this can be taken up as a separate user story as well as shown below; this approach would make the story small and simple as per the INVEST principle)
  • User should be able to see the enlarged view by tapping on the image thumbnail.
  • There should be an option to add product to the cart.
  • There should be an option to add the product in the Wishlist.

4. Do not try to break down the user stories in terms of Card, Conversation and Confirmation in one go. Just try to think of breaking down the requirements into smaller details in the form of user stories only with consideration of Who, What and Why. 
5. Once the stories are identified then relook and try to establish the relationship amongst the user stories and think whether some user stories can be clubbed in a bunch? If so, that bunch becomes your EPIC. 

Simply, an Epic is a large chunk of work having common objectives. An epic can be a customer requirement, features, or business requirements. The details that are required to reach an epic are called stories.

For example, I want to develop login functionality.

As you know, there are multiple ways you can do login/authorization.

• Form- based login
• Login with Google
• Login with Twitter
• Login with Facebook
• Login using OTP (One Time Password)

You can consider this bunch of user stories as a Login Epic and you can consider user stories for the entire user module as your theme. It can include, Register, Login, Logout, Forgot Password, Change Password, etc.,

6. Last, but very importantly, establishes the priorities amongst the identified list of user stories depending on the business needs.

Prioritizing depends of the importance or business value of the user story.

Especially, executing these agile tips in an iterative fashion will help you break down user requirements into functionalities that are consistent with the business. After detailed user stories, we can move to User interactions and design, but the accuracy of the interactions will depend on the iterations performed during the previous stages. Having high-quality reviews in place which will evaluate and marginalize these requirements from going haywire is a means to narrowing down the document. 

Some of the popular agile software is Agilean, Wrike, Trello, JIRA, Asana, Active Collab, Binfire, Planbox, etc.