SMART Requirements are Agile
SMART guidelines are used to assess requirements in waterfall projects. They apply to agile projects as well:
Specific. In Agile, it doesn’t exist initially. Specific relates to the final product. Requirements are captured during development, not documented in advance. However, the end result typically goes beyond the detail and specificity of traditional requirements. When broad requirements aren’t specific, they are typically broken down into several features in Agile, each of which provides specific functionality and can be more easily produced.
Measurable. The construction and evaluation of each feature focuses on measuring effectiveness. One of the most significant benefits of Agile is that performance and suitability measurement reviews are built into the development process. With a mindset towards prototyping, Agile features can be evaluated by users prior to implementation. When that cannot be done directly, for example, when a totally new business process is being created, the user-developer partnership used to build features in Agile reduces the risk of items failing to meet measurable business objectives.
Achievable. Feature sizing and prioritization ensures that achievability is regularly assessed. Features are examined for their integrity and ability to be produced during a sprint. Larger features are broken down into pieces that are more easily created, enhancing achievability. When the features can’t be broken down into manageable pieces, that’s a sign that they aren’t achievable. The developers and users can examine these features in real time to determine how critical they are and explore other ways to address the corresponding business need.
Realistic. In Agile, features are developed and accepted iteratively and in real time, versus weeks or months after requirements are documented in the traditional approach. Agile lends itself to realistic outcomes and can accommodate the latest changes to business needs. The nature of Agile means the team learns about features and their capabilities more deeply, allowing users to make features more business-friendly. Feature capabilities have greater integrity and support better business processes.
Time-constrained. The sprint schedule is ideal for ensuring time constraints are placed on feature creation. In addition, there is the added value of being able to easily change timeframes when business priorities change. Reprioritization and re-stacking of features for each sprint provide an ongoing focus on development timeframes. While this time management approach isn’t perfect, features that require more time than anticipated to develop are re-evaluated and assigned to subsequent sprints as agreed by the Agile team.
For more about Agile, check out Doug Rose’s Agile Foundations course.