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.
Fig. 1
In SpecDD, “requirement-driven” does not mean every requirement needs to be fully specified before starting the development and quality-assurance processes. A spec represents a product feature that may not contain the requirement details initially. The implementation of a requirement spec and its refinement often happen in parallel. SpecDD empowers a team to standardize its communications at the requirement spec level to document requirements understanding and to capture process intelligence.
The SpecDD implementation
Like Scrum, a development process is represented as a set of continuous iterations, often referred to as sprints. A single iteration normally takes two to four weeks, but can be longer or shorter as needed. Within the iteration, new development work is planned, committed, implemented, tested and documented.
The product owner populates the sprint with the set of prioritized features and defects. Assigned features are represented with stories, each with child tasks. Assigned defects often exist as standalone tasks without parent stories.
As work progresses, the tasks go through various workflow states and transitions. A simple agile workflow is used in helping to manage a task’s life cycle. As the task owner makes progress each day, the time remaining ideally dwindles down from its initial time estimate to zero. As the team self-manages to implement all of their committed tasks, a burndown report (example pictured below) best represents the team’s sprint workload progress.
Fig. 2
#!
Testing within a development sprint
The workload of a SpecDD sprint consists of a set of stories, tasks and defects that need to be implemented. A sprint workload should be estimated at the start of the sprint in terms of time efforts and task points. But should QA test tasks also be a part of the sprint workload alongside the development tasks? No.
A common mistake is to track all QA testing tasks alongside the implementation tasks, as well as tracking its completion based on time remaining. For an implementation task, it is reasonable to estimate the initial time required since it motivates the task owner to accomplish the work within the estimated target time.
For QA testing, however, creating all possible testing tasks with after estimating the time of a sprint is practically impossible. More importantly, estimating the total QA testing time serves no purpose in creating a self-motivated team. Without including the QA testing effort, the total time remaining of a sprint becomes a dynamic target. Time remaining for QA testing tasks only diminishes the effectiveness of a self-managing team.
In SpecDD, child tasks are used to represent the QA testing efforts for each development task. For feature development tasks, testing standards can be created based on their parent requirements. As the requirements are enhanced and documented, QA test cases are created to accurately define the quality standards for the requirement specs and stories. For defect-fixing tasks, the QA child tasks may or may not be linked with test cases, as the defect description often serves the purpose of the QA testing standard. The picture below illustrates the SpecDD Sprint Quality Model based on child QA tasks.
Fig. 3
The SpecDD Sprint Quality Model is created using a concept of “balance” to protect quality. The “makers” of the working software drive their efforts to convert the development stories and tasks into working software. The QA floaters are the “protectors” of the working software. They create QA test child tasks to prevent the parent implementation tasks from being claimed to be done without adequate testing.
The “makers” work toward creating accurate burndown reports. They are always motivated to hit the estimated time targets. The “protectors” slow down the time progression. Sometimes, they actually add to time due to newly reported bugs. The Sprint Quality Model creates a dynamic balance of these two forces to optimize the development productivity and quality.
For each SpecDD development team, one or two QA floaters are recommended to be co-located with the development teams. The QA floaters promote QA testing best practices and help each agile team member become a better tester. The test cases created and refined in agile sprint tests are important for assuring sprint quality. They also are accumulated into a more complete test-case library for future regression-testing needs.
#!
Regression testing
With the QA floater and QA sub-task model, an ideal SpecDD sprint could result in working software that is free of defects. Unfortunately (and realistically), the integrated product, after multiple sprint iterations, is bound to have some defects. Without a solid regression-testing practice, a large project with multiple teams will undoubtedly lack quality and scalability.
SpecDD uses QA test cases along with runtime environmental variables to formally represent and quantify the quality of a product. QA test plans specify the testing criteria for a product release. To make the execution of these QA test plans more flexible and effective, QA test cycles are used to represent the shorter testing iterations that cover a sub-set of all possible tasks in the QA test plan.
A test cycle contains a set of testing tasks derived from QA test cases by selecting the permutations of runtime variables. Such QA testing tasks can be executed manually or automatically by auto-testing tools. The picture below illustrates the relationship of QA testing cycles with development iterations.
Fig. 4
As you can see, QA test cycles are planned and executed but not necessarily synced with development iterations. While you want to naturally assign newly-found defects to the current active sprint, agile development requires the testing team to only submit defects to the product backlog. The QA regression testing team is responsible for finding defects, but they do not have the authority to decide when those defects are fixed. Having an independent team actually helps to create a more scalable agile process by finding defects earlier and prioritizing them in the product backlog.
For teams using waterfall-like processes, SpecDD helps them extend requirements management to support a product backlog. With the prioritized product backlog, teams can start to practice shorter iteration-based development while building self-managing teams with burndown reporting and daily agile exercises. They will quickly see productivity gains while maintaining requirements-driven development and quality practices.
For teams, currently practicing agile development, SpecDD helps to fully integrate requirements management with the product backlog, thus achieving total traceability. By adopting integrated agile sprint QA testing and building the QA regression testing with an independent QA team, multi-team agile projects become much more scalable.
Dr. Tieren Zhou is the founder of SpecDD, a hybrid agile development methodology for balanced agile development with integrated requirements and quality management. He received his Master’s degree in Computer Science and his Ph.D. in Artificial Intelligence from Kansas State University.
