Projects start with high level requirements. However, before progressing further one should know the detailed requirements. The following are some examples for high level requirements;
- We want to construct a three bed room house with dining, kitchen and a living room.
- The new water metro needs 10 new boats which can run on diesel and solar power
- We need a new airport which can handle at least 50,000 passengers per day
All these are examples for high level requirements. These high level requirements must be elaborated further before proceeding with further planning of cost and time.
Common tools and techniques used for requirements elicitation are;
- Interviews with relevant stakeholders
- Visits to other similar facilities
- Bench marking with the best in it’s class
- Digital modeling etc.
Once the requirements are collected, they are analysed further by experts resulting in agreed upon requirements. Approved requirements is the basis for further planning activities like;
- Development of the product breakdown structure
- Work breakdown structures
- Bill of quantities
- Cost estimation
- Scheduling etc.
How does it happen in agile projects?
Whatever we discussed so far is true for classical predictive project management which is very much applicable for construction projects of electrical, mechanical, civil, piping etc. In these domains, changes to scope is difficult to implement hence not encouraged. That is not the case with agile projects where changes to scope are encouraged. Examples of projects which are ideal for agile project management are;
- Any new product development
- Web applications
- Marketing programs
- Engineering phase of infrastructure projects etc..
In agile projects, high level requirements are captured in the product backlog by the product owner. Product backlogs are allowed to grow indefinitely. Product backlogs are prioritized into a Minimum Viable Product (MVP) first. The minimum viable product is is developed on priority based. Once the MVP is launched, other features in the product backlog are prioritized. Before the start of the iteration (sprint), the prioritized product backlog entries are elaborated into user stories. User stories contain;
- Product backlog entry
- Detailed description of the feature to be developed
- Acceptance criteria
- Conversations about the feature to be developed
User stories makes it easier for the development team to understand the features better before estimating the story points and effort. While detailing the product backlog entries into user stories, teams use;
- User story writing workshops
- Bench marking with similar projects etc