Yesterday, I gave you an overview of the software development method Scrum. My previous post included a high level view of the overall Scrum process. Missing in this picture were any details on the Sprint phase. During a Sprint, a new version of the product is developed. At the end of each Sprint, a new shippable version of the product is ready, which is completely tested and documented. In case of small projects, a Sprint should not be longer than four weeks. In larger projects, a Sprint can be up to three months long.
Each Sprint must have the same length, because Scrum is based on the idea of fixed time-boxes. This concept is also used in other reoccurring meetings. For example, at the beginning of each Sprint a Sprint Planning Meeting is conducted. In the first four hours of the meeting, the Product Owner together with the Team defines "what" should be developed during the Sprint. Afterwards, they define "how" to achieve the goals of the current Sprint. The outcome of this planning session is documented in the Sprint Backlog, for example as user stories.
Items in the Sprint Backlog are assigned to different developers of the Team. An assigned item should be small so that it can be implemented in one or two days. Each developer first develops a test case for a given feature. As the feature is not available yet, this test case will fail. In a second step, the feature is implemented so that the test case defined before is passed. This kind of approach is called test-driven development. The test cases are used instead of writing a documentation of the software design. This approach includes continuous refactoring of the code. Refactoring means restructuring the code without changing the behaviour. Effective refactoring is possible, because the test cases ensure that no functionality gets broken by changes. If the implementation of a feature is done, the feature is removed from the Sprint Backlog and the belonging Sprint Burndown chart is updated.
Each day at the same time (fixed time-boxes again!) a Daily Scrum meeting is conducted. Every member of the Team presents what he has achieved in the past 24 hours and what he plans for the next 24 hours. Obstacles are discussed and solved during the meeting. In the BPMN diagram, I attached an interrupting timer event to the implementation sub-process to model the occurrence of the Daily Scrum meeting. If needed, the Scrum Master can be involved in the Daily Scrum meeting, for example to mediate problems between team members. The Product Owner participates in the Daily Scrum meeting, too. For example, the product owner can clarify items in the Sprint Backlog or discuss with team members the priority of items.
At the end of a Sprint, there should be no items left in the Sprint Backlog. If items could not be completed during a Sprint, they should have been removed from the Sprint Backlog by the Product Owner before, because development progress is transparent due to the Daily Scrum meetings. This is an important point, because in non-Scrum projects it often happens that delays are only discovered at the end of the development cycle resulting in delays of product shipment. In case of Scrum, product management can change priorities early on ensuring that the most important features are shipped on time.
A Sprint is concluded with two meetings:
- Sprint Review: In the Sprint Review meeting, the product and the new features are presented and demoed. The Product Owner presents the current state of the Product Backlog. During this meeting, team members can learn to better estimate the effort needed for certain features. Technical challenges and their solutions are discussed and future directions can be derived.
- Sprint Retrospective: The second meeting focuses on the development process itself and not on the product developed. This is especially important for teams who just adopted Scrum as their development method. Lessons learnt and improvements can be discussed for the next Sprint. The meeting is led by the Scrum Master.
Both meetings are important to ensure continuous process improvement. They serve as a knowledge transfer between all involved participants. Again, both meetings are time-boxed, for example every meeting being half a day long.
As we can see, the Scrum Sprint phase is quite unique, because:
- Sprints always have the same fixed length
- Sprints must deliver a shippable product
- only small items of one or two days work are assigned to a developer
- Daily Scrum meetings allow a daily change of development priorities
- Daily Scrum meetings allow immediate actions to fix problems in the development process or technological approach
- test-driven development is employed
- continuous process improvement is directly incorporate (Sprint Review and Sprint Retrospective meetings)
- ...
I think my BPMN model of Scrum could be further extended. For example, it would be interesting to model the details of the Daily Scrum meeting or refine the implementation sub-process. I hope this little excursion in the software engineering domain showed how to use business process modelling for defining and understanding software development processes.
