Rough Design Up Front can help; create project momentum, shorten the overall development time, reduce risk, and help form a new team. But, deciding when the rough design is good enough and the work of construction can begin is a crucial milestone in the life of the project. At SPAN we often start a project with an inception workshop, for smaller projects the workshop may be sufficient, but for larger projects an iteration, or two, elaborating a rough design may be required before construction can commence in earnest.

Starting in the workshop, and continuing after, we collect and refine requirements in two distinct areas; functional scope, and Business Objectives.

Functional Scope (Epics and Stories)

Epics and stories collectively describe the functional scope of a solution, they comprises all the intended features and functions. We usually triage the scope into three distinct priorities based on business need and potential to reduce risk. Finer sequencing of the backlog can happen later, at this stage a rough prioritization is all that is needed.

Business Objectives

Business objectives can be divided into two parts, solution capabilities and initiative externalities. As discussed before setting objectives for agile projects is a useful practice for agile teams. With a little effort it is possible to frame the entire initiative with meaningful and measurable targets that define success and can be used to calibrate progress.

Solution Capabilities

Solution Capabilities define important required performance characteristics of the solution. For example, a new vehicle could have a target set for it’s fuel efficiency as “21 miles per gallon in normal freeway traffic”. For most solutions it is useful to define a few important target values for measurable capabilities. selecting the right capabilities, defining meaningful target values and measuring them is often challenging. Teams that fail to do this usually fail to deliver the necessary capabilities because they have no target to aim for, and no yardstick to measure success.

Initiative Externalities

All solutions are built in a business or political context. This context can often be summarized as a budget and a time-line made up of externally defined milestones. Design to cost and deliver on schedule, is a fact of life for many businesses. Earnings calls, trade shows, and product launch schedules mean that delivering a viable set of features by a specific date is essential for success. Rather than fight these externalities, it is often better to produce a rough design that can plausibly satisfy the most important requirements well within the deadline then evolve the remaining features.

Co-Evolving Requirements and a Rough Design

Creating a rough design is an iterative process with both requirements and design being developed in parallel. It is a negotiation between team members and stakeholders. The design artifacts embody the agreements and decisions that the team has reached. The process of requirements refinement and re/design continues throughout the life of the project, but, knowing when to transition the main focus from design to construction requires balancing several factors. The maturity of the team, their familiarity with the problem domain, the size and complexity of the project, and the extent to which the requirements can be pre-stated or must be discovered, are usually principal factors in deciding when to begin construction.

The rough design usually comprises a handful of diagrams that represent a conceptual model of the solution and collectively explain the approach we are taking and how the solution will work. We continually review the rough design against the requirements all the while asking the following questions.

Does the conceptual model account for system requirements at a reasonable level of abstraction?

• The conceptual model is sufficiently generalized when it can account for all significant epics and stories in a concise way that reduces complexity by consolidating similar features.
• The conceptual model is sufficiently specific when domain specific concepts are reflected in the design of core components, and domain specific terminology (nouns and verbs) are used consistently throughout the design.

Can team members use the design artifacts to convincingly explain the solution to stakeholders, and each other?

• How will the solution deliver the required features and functions?
• How will the solution meet its capability targets?
• How can the solution be delivered in time and on budget and thereby meet meet external milestones?

Starting Construction

Construction can start when these questions can be answered satisfactorily and a backlog of stories and tasks has been prioritized covering the construction of the majority, but not all, of the design. How far we go with defining the backlog depends of the business need. If we are building to cost or building to a deadline we try to define at least 80% of the solution. If the deadline and or cost is less important than some other business outcome then we may start with as little as 40% of the solution defined.

When the team responsible for building the solution can confidently look each other in the eye and claim they understand what they are about to build, and have a reasonable plan for building it, when they feel confident they can work out, as they go along, what they don’t already understand. The design is good enough.

Inevitably, during the course of the project, we have to rethink many of our design decisions and plans. We seldom, if ever, implement a design without change - but this does not mean the initial work is wasted - Far from it. We change our plan because we have learned valuable lessons, or need to adapt to changing circumstances. The initial preparation makes the inevitable adjustments and reorganization far easier as the team has already learned to negotiate and compromise with each other, considered and evaluated many alternates, and is armed with a common vocabulary and understanding of the problem domain.