I get asked a lot about how does a design document (dd) fit into SCRUM. There is generally a deal of concern that the dd slows the development process and even concerns that it’s a fall back to waterfall development.
So, just to remind, the dd can be really small. It can be as small as a number of dot points (or a few sentences) in an email or a photo of a whiteboard used in a design/planning session- particularly for small pieces of work.
A dd works well within SCRUM as a the output of a spike. Reminder about spikes:
“A spike in a sprint can be used in a number of ways:[1]
- As a way to familiarize the team with new hardware or software
- To analyze a problem thoroughly and assist in properly dividing work among separate team members.
- Spikes tests can also be used to mitigate future risk, and may uncover additional issues that have escaped notice.”
A distinction can be made between technical spikes and functional spikes. The technical spike is used more often for evaluating the impact new technology has on the current implementation.
Source:https://en.wikipedia.org/wiki/Spike_(software_development)
What’s really important about that statement is: “The technical spike is used more often for evaluating the impact new technology has on the current implementation”. This is one of the primary reasons we use a dd. It’s to protect the existing implementation and by seeking feedback from experience developers, tech leads and architects the developer is reaching out and using the experience and knowledge of the development team who generally know the most about the current implementation. They are are in a great position to advise on technical direction to avoid negative impacts on the current implementation.
The dd does not always have to be produced via SPIKE, but certainly in the case where the SCRUM team is considering a new feature with new patterns/libraries/hardware etc.. then it may well be worthwhile investigating a Spike. I like the dd as an outcome of the spike because it is actually meaningful output and can be accompanied by a prototype. I also like the idea of adding acceptance criteria – that’s really for the tech lead/senior developers/architects to accept as part of their review.
Doms Code 
A great set of ideas & pointers. Really enjoyed reading them.
When doing a Spike in our sprints, the output 9/10 is a design document which is then distributed to or demonstrated to the rest of the team. It works really well in getting buy-in on new ideas or spotting wrong assumptions
Not sure if my comments were posted, so trying again…
Really enjoyed reading the posts – some great pointers and resources.
We also use Spikes as way of creating design documents – its a good way to ensure that the spike has an outcome. We then share the documents between the team members making sure that everyone understands or has a chance to correct any wrong assumptions made.
Steve – sorry for the delay – excellent feedback – I really think the point you make about sharing the documents with the team members is extremely useful. Not just peer review, but also a learning opportunity for junior developers to see what’s being designed .