Thirty years ago, traditional methods of project management in software development were not efficient enough to embrace changes in the project’s requirements. Thus were imagined the agile methods. Today in the construction industry, a question of feasibility arises whether it is possible to apply agile methodology to improve building information modeling (BIM) productivity. In this series of posts, we will discuss how to transpose a classical workflow in software development in the world of architectural design.
A big advantage of agile methods in AEC will be this concept of task done. The workflow starts with writing user stories, prioritizing backlogs, inclusion of features, issue tracking, team collaboration and responsiveness to integration and client review.
User stories are sticky notes that are written to specify ‘what’ and ‘why’ software features are required from the client perspective. Then, the developers will collaborate with the stakeholders to find solutions. The team will work on these user stories as they are automatically linked with the tasks in the next iteration. In agile terminology, iteration is a period in which tasks have to be completed is referred to as a sprint, which usually lasts from one to three weeks.
Let us now explore the step-by-step approach to working on backlogs and user stories in the construction domain. Just take an example of a complex roof. We have to clearly know the roles of persona (architects, engineers, etc.) and tasks involved so that we can check out how the product is developed to the project programme expectations and the contribution of each person.
Architects are responsible for defining aesthetic specifications and performing aesthetic validation. They focus on the overall design and the visible design. So, they define the general plan for lighting, floor plan, fittings, and final touch. Meanwhile, engineers are responsible for defining technical specifications and performing technical validation.
If architects draw the glazed curtain wall of a building, they just have a global view of his building, while engineers have a lot of specifications.
A user story is a powerful tool for associating tasks with the context and defining the clear details of a picture. If we split user stories with the INVEST principle, we come to know how to process them with standards.
- (I)ndependent: prioritize user stories without overlap
- (N)egotiable: modified to the business requirements
- (V)aluable: valuable for the business or the customer
- (E)stimable: categorize user stories based on size in order to prioritize them in a better way
- (S)mall: keeping the story short to fit into an iteration
- (T)estable: testing criteria before writing user stories.
We need to define user stories based on the end user requirements first and direct discussion with the project owner. If this is not possible, some design competition, for example, we need to define them based on project programme.
As user stories clearly define the purpose and the way of processing tasks, the AEC members will have a better understanding of the client needs and programme details. With the perfect implementation of the INVEST principle, effective planning of tasks and production become much easier.
- “How to Write Great Agile User Stories”
- “Agile project management concepts applied to construction and other non-IT fields”