By Tieren Zhou – September 24, 2013
Agile is the most widely accepted and practiced development methodology today. Interestingly, agile has gained its popularity not by replacing other methods, but by fusing with them. Real-world agile project success has proven the future of agile is going be a hybrid agile methodology.
SpecDD is a requirement-centric hybrid agile development methodology. It is designed to provide a single framework to manage both agile and traditional projects within a set of principles.
Requirements in SpecDD are represented with requirement epics, MS Word epics, specs, and document attachments. Specs are the normalized requirement items used to quantify requirements. Identical to Scrum, the development project implementation in SpecDD consists of a set of continuous iterations, with each iteration designed to convert a set of committed items to the working software.
Unlike pure agile, however, SpecDD includes models to represent the requirement and QA testing processes. Requirements are used to populate the product backlog and the development sprint workload. QA test cases are created before, during and after the development iterations. To make the QA testing practice scalable, an independent QA team is recommended to work with agile teams to perform testing within development sprints as well as total regression testing.
What is SpecDD?
SpecDD provides a framework for teams to practice agile, but with guidelines to mix agile functions with traditional project-management best practices.
• Requirements are represented as artifacts above the product backlog. Requirements are retained while product backlog items are consumed to generate the working software.
• Requirements are linked with QA test cases that can be created and improved before, during and after development sprints.
• A development sprint in SpecDD generates two deliverables: the improved working software, and the improved requirement representation.
• SpecDD welcomes changes, but mandates requirements and their changes be documented to retain the process intelligence related to such business logic/idea creation and refinement.
• SpecDD provides a scalable quality model for both assuring the quality of a development sprint and the total quality of an integrated product.
Benefits of SpecDD
SpecDD empowers teams to achieve scalable and repeatable development success by improving their productivity and innovation capacity.
• Standardizing team communication at the requirements level can boost the team’s capabilities for product innovation.
• The requirement and product backlog integration provides a clear, scalable model for multi-team and large agile projects.
• The independent QA regression team and joined QA-floater model is more scalable for total quality management.
• It enables an enterprise to plan at the product-requirement and business strategy levels for agile and non-agile projects.
Quantify requirements to drive total traceability
As illustrated in Figure 1, a SpecDD project starts with requirements management. Requirements drive the formation of the product and sprint backlogs for development. QA test cases are created based on these same requirements. QA test cases together make up the QA test library, which defines the product’s quality standards. The QA regression testing team then creates the QA test plan and executes it with multiple test cycles.
SpecDD manages requirements with epics and specs. An epic represents a rough high-level idea, often too general in scope that needs to be broken down to specs. A spec represents a new feature or enhancement, and may require one or more development tasks to implement.
A spec does not need to be fully understood or documented before starting. During its implementation, the working software itself will help the team better understand the requirements and further refine them. New and improved documents and attachments are often added later, including newer business logic models, updated graphical user interfaces, or new technical design documents.
When a spec is assigned to the product backlog, a story is created to represent the commitment of its implementation. It is highly possible that one spec may require multiple stories to represent the fact that a requirement spec may need to be implemented multiple times.
Figure 1 illustrates the relationships between specs, stories and tasks. A requirement spec is assigned to development as one or more stories. Each story may have one or more tasks. Each task then may have one or more QA test sub-tasks.