The big question in agile projects is when to start with the design and test design for a specific work item – in my case a smart use case? In traditional waterfall styled methodologies, analysis and design for the full project will be finished even before the first line of code is ever written. In agile projects, and in our methodology Smart in particular, this is certainly not the case.
My guideline is easy, and is directly related to the lean principle Eliminate Waste. That is, keep your stock as low as possible, as having stock costs money. This clearly goes for production environments, but is also very valid in software development. In this case, having unimplemented, but fully designed smart use cases (or other work items, such as stories or features) lying around, is unnecessary stock. Now, there are two major risks involved in having this stock:
- Changing insights. As the project proceeds, insights change, people develop new ideas around the software to be build. One of the possible consequences of these new insights is that earlier designed smart use cases (or other work items for that matter) might no longer be valid, and additional design work needs to be done. It can get even worse as these work items may even be dropped and never get implemented. In this case all design work has been done for nothing.
- Less time. The team working in the project gets more knowledgeable about the business processes, smart use cases and the software to be build, as the project progresses. As a consequence the time required for design and test design of a particular smart use case will be less when this is done later in the project.
Because of these consequences, my clear guideline is as follows.
Postpone the design and test design of your work items / smart use cases as long as possible, until the moment that the design is really required – that is, the moment the use case will be constructed.
Ideally, you will only start the design and test design on the same day that the code will be generated and built. However, in some cases it is inevitable that design starts earlier. This might be the case for instance when during design questions need to be answered by third parties, and answers are not received immediately. Think of questions around the availability of hardware, or whether another department is responsible for implementing some crucial web service. Under such circumstances, it is unavoidable to start design and test design earlier, to avoid having no stock at all at the time a smart use case needs to be built.