job.answiz.com
3 Answers
  • 4
Votes
name
name Punditsdkoslkdosdkoskdo

How to deal design in Scrum?

How do you deal with design in Scrum? Do you still have well written design documents for each scrum iteration? Do you just do design notes featuring UML diagrams? Or do you just have well commented code?

Each iteration may involve changing design so I just wanted to know how people capture this so new developers have an easy job of understanding the domain and getting on board as rapidly as possible.

Scrum is an iterative and incremental model based on agile values. That means you don't have a separate design phase. The idea is that you should constantly be dealing with design, just as you constantly are dealing with analysis, implementation, testing and integration throughout the project.

You need a bit of planning for this to work. Enter the sprint planning meeting, where the team estimates tasks for the sprint ahead. Most people don't realize this is not only an estimation meeting, but a design effort as well. For example, a task might be "Add code for new car model". You cannot estimate this yet, you need to know a bit more. So the team discusses the design and comes up with a broad solution ("subclass Car?") and adds that as a reminder to the task. You rarely need more formality than that. You now have an idea how to solve the problem. You don't have all details yet and that is fine, you know enough of the design to be able to make a comfortable estimate. Without having to create any diagrams at all (at this point).

For actual physical documentation, I recommend creating a systems overview diagram up on a wall for all to see. The overview only needs to have the most important classes and modules included and should rarely have to be updated. Also, creating a few state diagrams for the most important classes in the system is very helpful. Sprinkle with a few select sequence diagrams of typical use cases to make it easy for people to quickly see how things are connected. I assume you can generate class hierarchy diagrams from your code, so that problem is easily solved.

Note that all diagrams are created after the actual implementation. This is keeping with the "working software over comprehensive documentation" and just-in-time design.

And yes, readable code is definitely documentation.

  • 0
Reply Report

just because it is scrum does not mean everything changes each sprint!

Scrum is about doing what is necessary (but no more). You still need to do the design and you still need to document. Its just the amount is not fixed nor how to do it.

Part of the planning each sprint is deciding what needs to be done. If something in the backlog needs to be designed because it impacts other things then you need to add a specific task for the design processes and do that before the implementation task.

  • 3
Reply Report