Product Requirement. Guideline

As the process of Project Management continues to integrate with and become a core success factor in new product development efforts, it is essential that a formalized, predictable approach to Product Requirements be used.

Product and product component requirements address the needs associated with each product lifecycle phase.

Product Requirements workflow helps define the components of an operational product and the method in which these components must integrate to achieve desired results.

It minimizes the probability of investing additional development time to redevelop or later modify by delivering a clear, identifiable set of specifications for a product effort.

Today, in this article, we’ll dive into product requirements structure. It serves as a guide and some practical things for business and technical teams to help build, launch, or market the product.

Guideline

The end goal of all meetings and discussions around new functionalities is to create and size tasks for better planning (Definition of Ready for documentation). The steps to be taken are quite simple to follow.

Draft → Requirements Done → Ready For Sizing → Completed

1. Product Owner (PO) brings to the table the idea generated by the business need.

• PO transforms the idea into a requirement doc (DRAFT specification)
• PO starts to create tasks/user stories and/or Epics.

2. After the DRAFT of the specification is completed, it must be discussed with the Tech Leads.

• A meeting is being held to originally explain the feature and make sure REQUIREMENTS DONE.
• Questions & Answers (Q&A) session can be held during the same meeting or separately to make sure the specification is READY FOR SIZING and artifacts (Epics/user stories/tasks) are amended if exist.

3. The assigned person (Tech Leads, Business Analyst, Project Manager, and preferably PO) creates a list of user stories to be evaluated in T-Shirt sizes or story points/hours.

• Stories/Tasks are listed within the same document with attributes such as

➔ description

➔ acceptance criteria and constraints

➔ other notes and attachments that bring clarity

• Stories are discussed and then sized depending on the level of details. Only then the requirements as a specification are COMPLETED.

4. These Epics/stories/tasks are then prioritized by PO and added to a task tracking system.

• They are available for Sprint planning regardless if it is done by Integration Team (scaled Scrum) or an individual team.
• Further breaking down into tasks (UI, front-end, back-end, testing) is performed during the planning meeting.

Requirements Management Plan is an essential part of any project. It encompasses various types of information, including a management approach.

Statuses

DRAFT — the initial requirements that need to be shaped by the Product Owner.

REQUIREMENTS DONE — the requirement document is completed from the Product Owner’s perspective.

READY FOR SIZING — all questions are being cleared, and stories in a document are ready to be discussed and estimated.

QUESTIONS — there are open questions to the Product Owner and blockers.

COMPLETED — the specification is evaluated, and tasks are created in Jira.

Tasks Flow

For successful delivery in an agile environment, use the confirmation questions to ensure the alignment with business objectives and expectations:

➢ Will we release during this period? Perhaps even on what date?

➢ What will be fully developed and delivered?

➢ What will be developed enough that a subset of it can deliver value?

➢ What other deliverables are needed? Is there documentation that must be updated?

➢ What measurable quality level is expected? Is the project successful, but some low-priority tasks were cut off?

Jira tasks flow

Find the sample of the task flow in Jira, a task management system by Atlassian.

Below, is our vision of how tasks flow and QA processes should work.

At DevCom we bring strategy and product design, combined with digital engineering excellence. We put a lot of emphasis on five, short pre-defined critical phases of the development lifecycle, with each cycle resulting in the delivery of potentially shippable functionality. Contact us.