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.
Anna Forss on
Yet again, wonderful to document the process. I have some ideas here too. But first: I would say that I would like a presentation of the product backlog in the process and a definition of the product backlog. The product backlog items are not just owned by the product owner. Yes, he owns the descriptions and the priority of the items but the team owns the estimation of each item.
But over to the sprint, I would not say that the sprint planning meeting is generally hold by the product owner. The inital part of the sprint planning meeting is hold by the product owner when it comes to what to work with, but the team is responsible for what they think they can accomplish, how they are going to implement and the estimations.
We don't only need the product backlog as input to the sprint: we also need the current resource situation, so the team can evaulate how much work can be done: do we have the same resources? are there any big events which might affect us?
It is essential to point out that the product owner does not own the sprint backlog! This is the team and more specifically: the scrum master.
I also think that it's important to point out that the team are everyone which creates business value. This means that if designers, tester, business people, etc are working on sprint backlog items, they should be included in the team definition.
The scrum master facilitates the daily standup.
I miss the word impediment, since the responsibility here is crucial to the process. The team members are responsible for identifying impediments and when an impediment has been identified, it's the responsibility of the scrum master to make sure that the impediment is handled. This does not mean that he has to remove all impediments, but he makes sure someone does.
There is no clarity on how items are passed to team members. An important factor of scrum is the indivial taking the sprint backlog items instead of them being handed out by a project manager. This also goes with which product backlog items turn up on the sprint backlog. Yes, the product owner specifies what has the highest rank but the scrum team is responsible for selecting which items are placed on the sprint backlog
I also miss the handling of bugs: this is an important issue and there are many views and alternatives on how this is handled in the scrum process. If you have questions, please get in contact with me and we can discuss it.
An output from the sprint is also an updated value for velocity. Dependent on how you use and calculate velocity, this might differ, but in all methods I've seen, velocity is always recalculated after each sprint.
I also miss the handling of breaking a sprint. This should not be your average scenario, but most people face this sometimes and when it happens, it is important to have that process well documented. Again, if you have questions, please get back to me.
Finally, a question. Some of the artifacts (sprint retrospective) is not part of the scrum process even if they are very common. Is it important to identify what is hard core scrum and what is recommended implementation?