Project/System technical specification documentation
Hi Everyone.
Say we have a very large technically complex SCRUM project with say 40 plus developers and 20 plus testers and a large number of BA's .
Assume all the jira tickets themselves are technical tickets which are unclear, incomplete and at a high level - the JIRA ticket does not explain all the details of what the system should do. Also assume that the personnel on the project will change over time.
Under SCRUM , what 'technical specification' type document(s) should be in place if at all, so that :
- developers can complete each individual technically complex JIRA (although the JIRA itself is written at a high level)
- testers can use the document to then be satisfied that the code works as they expect during testing
- anyone else interested (e.g Test Manager , Business User, Scrum Master ) can understand what the system is supposed to do and effectively what the developers have done
Before SCRUM I would have expected a 'technical specification' for each ticket or group of tickets , that makes it absolutely clear what a given technical JIRA ticket or group of tickets are supposed to achieve and gives information as to what testers can go ahead and test. Anyone else can then look at the technical specification and understand what the code does achieve i.e how the system works .
These tech specs would then be grouped together to be cross referenced to the overall system design the result being that anyone could gain an overall technical understanding of the project .
In complex work, more is unknown than known. A Sprint Goal will mitigate a risk or uncertainty of at least modest significance. The items on a Product Backlog are there to feed the discussions in Sprint Planning about what a meaningful Sprint Goal ought to be. They need be no more exacting than that. A Sprint is a minimal leap-of-faith experiment to establish what is really needed in a Product.
For the experiment to be empirically valid, the quality of the work must not be in question. The place for a rigorous technical specification is therefore the Definition of Done. Recognize and allow the scope of work to be emergent and negotiable.
If your Jira tickets correspond to Scrum's Product Backlog Items and are unclear and incomplete, how can the team assert they can be completed within one Sprint? The purpose of Product Backlog Refinement is to decompose and define Product Backlog Items so that the team can make this assertion and come out of Sprint Planning with a high degree of confidence that they can achieve their Sprint Goal based on the work to support it.
The work should also be clear to other stakeholders. One of the Product Owner's accountabilities is ensuring the Product Backlog is clear and understood. The stakeholders should understand each Item's current state (such as where it is in the Product Backlog, whether it's been selected for the Sprint, and whether it's done) and what it means for a Product Backlog Item to be Done (via the Definition of Done).
I agree that, in a complex system, you probably don't want to always have to reconstruct the system's state from a long history of Product Backlog Items. I've found that maintaining as-built system documentation as part of the Definition of Done works well. Agile Modeling gives good principles and practices for designing and modeling systems consistent with broader agile values and principles, while lightweight documentation templates like Arc42 help structure system design information.