SpecDD Process

In SpecDD, a development process consists of continuous iterations. Within an iteration, new development work gets committed, planned, implemented, tested, and documented.   Development work is specified based on quantified requirements.  SpecDD models software requirement with two layers, specifications and requirements.  Requirements are used to manage documents, ideas, visual pictures, sound and other digital files.  Requirements could be large size documents from different customers, or simple email or notes from internal teams or from customers.  A Spec often represents a new feature or enhancement; and may require one or multiple development tasks to implement such a spec.  Since a spec is linked with one or multiple requirements, and is linked with relevant specs, developers can better understand the business logic for each tasks assigned to them.  

 

A SpecDD interaction, or Sprint, has two deliverables, the working software that get incrementally generated on daily bases, and also the improve product design.  While the working software is the primary measure for the development and QA testing work and for what delivered to customers or product owners, the quantified requirements and product design are the primary standard for assigning any implementation and QA testing work.

 

In other words, in SpecDD, the quantified requirements are formally represented with specifications with links to supporting requirement documents, and linked with other related specifications.   While they may not be the complete documentation of what is developed, but they also serve the purpose of what developed is according to such “conceptual product”.  

As a result, the “conceptual product” does represent what can be best documented for not only the functions, features, and defect fixing of a working software, but such design, the “conceptual product”, also contains the human interaction and the decision making processes.  That is why SpecDD captures not only the requirements and the programming, and the QA testing activity, but also it captures the intelligence of making such product feature decisions.  Therefore, SpecDD can better assure the long term success of a project.  The decision points are captured as part of the processes and lives in the project data.  

 

 

Meetings needed for SpecDD

 

SpecDD Sprint planning meeting
The sprint planning meeting is the venue for the product managers to pick and assign work to their teams for the duration of the sprint. The meeting usually begins by reviewing the high-level concepts that the product managers have created prior to the meeting. These concepts represent the work to be done as described by existing customers, sales and marketing staff, market conditions, the vision of the software architects, or other driving forces.

The product managers are tasked with presenting the concepts. The concepts must be expressed in the terms of user experience and value. A product manager will explain the user experience to the best of their ability. This requires them to take the view of the end-user. What is it that this function will be used for? How will the user gain value from it? What are the external conditions that must be met by this feature?

All of these items should be neatly summarized into the initial concept’s specification and its’ linked requirements.

The team will then prioritize these concepts based on maximum value to the project. For example, a customer may be demanding a new feature. However, implementing this feature would mean delaying another aspect of the project. The product management team will have to weigh the customer’s demand with the good of the whole project – and sometimes the customer’s feature will be delayed to another sprint.

The meeting should take, at minimum, 1 hour. At the end of the meeting, there will be a clear roadmap of what functionalities will be developed over the sprint. They will have a work-breakdown structure that contains a rough idea of what the areas of work needed to achieve these features will be. Part of this structure will contain the dates that various activities are due, and the resources that are assigned to work on them. These are initial projections and assignments: they may change later in the sprint.

Meeting Attendees:

Product Managers

Project Managers

Development team leads

QA team leads

Development and QA team members (optional)

Results of meeting:

General roadmap of what will be accomplished in the Sprint

Understanding for what resources will be needed (which teams are working on what features and when)

Prioritized list of work to be done for the sprint

Due dates on when the highest priority items must have designs (and who is responsible for those designs)

SpecDD daily development meetings
The outline of what will be developed during the sprint has already been decided (in the sprint planning meeting), the actual day to day implementation plan and task management happens at a lower level. Daily meetings are used to facilitate these activities. The development team, in conjunction with their team lead, will create and review the tasks needed to actually build the functionality described in the specifications. They will also review and revise estimates on how much time they need to complete each task.

The team leads will review several items daily with their team:

First, they will record the progress of the previous day. This progress is shown through tasks that are completed, in a new state of their workflow, or have updated estimates. The development team should be constantly updating when the they believe is remaining for each task.

Second, they will review the estimates for the current tasks. This is where the development has their opportunity to raise any questions they have with the specification. Team members might explain their understanding of the feature, and why they have broken the work down into the tasks they’ve created. If no tasks exist for the feature, they will use this opportunity to create those tasks. Each task will have a clear owner, various stages in its lifecycle, and estimates on the time remaining to complete the task.

Meeting Attendees:

Development team leads

Development team members

QA team leads (optional)

QA team members (optional)

Project managers (optional)

Results of meeting:

List of tasks needed to implement function

Owners of tasks and deadlines

Updated estimates of completion

SpecDD daily QA meetings
Testing is a critical part of any software project. With a SpecDD project, testing is covered in multiple areas. It is often productive to include the QA and Development daily meetings, since development and testing happen concurrently.

The purpose of the QA test meetings are to highlight the areas that QA will test for that day. This is related to the development tasks and specifications that have been completed up to that point.

The QA team reviews their testing goals for the specifications and their test plans to meet those goals. The QA team lead will describe the specification to the QA team. Optionally, the development team lead might review the design or provide a demonstration to the testing team. The testing team will then assign (or create) testing tasks based on templates that they have previously created. The templates are linked to a specification and will test the functionality described in the specification. Each task is assigned and the testers are able to clarify their understanding of the specification and concepts they need to test.

Meeting Attendees:

QA team leads

QA team members

Development team leads (optional)

Development team members (optional)

Project managers (optional)

Results of meeting:

List of test templates to be used

List of tasks needed to test function

Owners of tasks and deadlines

Updated estimates of testing completion

 

SpecDD Sprint review meetings
At the end of the sprint, a meeting is held to review the progress made for that period of time. This meeting is held between the Product Managers and Development team leads. The goal of this meeting is to highlight the work completed (and tested) in the sprint. The development team leads will walk the product managers (and other attendees, such as the Chief software architect) through the features as if they were the customers.

This meeting determines whether a concept has been clearly expressed: both in the specification as well in the working software.

Meeting Attendees:

Project Managers

Product Managers

Development team leads

Development team members (optional)

QA team leads and members (optional)

Other stakeholders (Chief Software Architect, etc. – optional)

Results of meeting:

Understanding of work completed within the sprint

Understanding of gaps of understanding in specifications or concepts

 

SpecDD project management meetings
Throughout the project, management monitors progress and efficiency. The project management meetings are not related to any single sprint. They exist as means to balance the low-level daily tasks and the high level concepts with the realities of the development team’s capabilities.

During the project management meeting, team leads, project managers, and executive management review the progress of the project. They analyze resources: is a team adequately staffed to handle their deliverables? Do certain teams outperform other teams, and why? Are key team members planning time off, and what will happen during those times?

The project management meeting ensures that the high level vision continues to progress and will be delivered within the needed timeframes.

Meeting Attendees:

Project managers

Development team leads

Executive managers

Product Managers (optional)

Other stakeholders (Chief Software Architect, etc. – optional)

Results of meeting:

Understanding of work completed within the sprint

Understanding of gaps of understanding in specifications or concepts