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.
ARIS model
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?
Hi Anna,
I intended to answer your points today in the morning after answering also the points in my first post, but than a lot of work dropped by and I am still fighting with it :-) Therefore, just a short answer for the time being.
You raise the point that a certain activity is not executed not only by the Product Owner, but instead the Team must be involved. You are absolutely right, but we are experiencing here a limitation of the modelling language, because BPMN doesn't allow me to visualise if several people are involved in a certain activity. I could do that in EPCs, but not in BPMN. Therefore, I put tasks in the lane of the person, who should lead the activity. That's not a good solution, but at the moment I don't know a better way to do it.
You also noted that certain data artefacts like the Sprint Backlog are not owned by the Product Owner. I think this is a misunderstanding of the notation. BPMN doesn't make any claims about who owns which data. That's simply not expressed in the notation and also other notations like EPC don't have constructs for that. In ARIS terms, I would use a data model to express responsibility for certain data artefacts. But I can't do that in the BPMN process model.
That were just the easy spots, but I think I will need to update my diagram to fix some of your other remarks...
Again, thank you very much for raising all those valid points!
Great discussion. We are soon to document our development process in ARIS so this will be a great starting point.
The point about the sprint and product backlog is not only about the artifacts but who is responsible for the creation: the sprint planning meeting for example is divided into two processes. The first process is owned by the product owner where he explaines the highest prioritized items. During the second process, facilitated by the scrum master but owned by the team, the actual stories are selected and the how to is established. The reason for me pointing this out is that this division is one of the bigger principles of the process and is often missed, which leads to missing out on many important gains of the process
Ivo, that's correct if you build process network (read: multiple models explaining the different phases of SCRUM) and you want to reuse that object. If I read the spec correctly, the data object describes a specfic instance in *this* process and the data store describes data that can be reused in multipe processes.
This is definitively a different interpretation of data objects/usage that is built into the ARIS method and explained by Uwe elsewhere. On my current project we avoided this discrepency by not using the BPMN data objects, but modeling data objects (clusters, etc.) in FADs and data models.
Well, Roland, that's a persistent bug with me. The BPMN spec reads: (1) A DataStore provides a mechanism for Activities to retrieve or update stored information that will persist (2) beyond the
scope of the Process. So I read (1) and probably refuse to comply with (2). Why? First I'm not sure what would be the use of tagging data as local or global (persistence?), I would prefer 'static' and 'transactional' or other more meaningful categories at least when at CIM and PIM level. Second, more importantly, a "backlog" is a log, so reading just (1) makes sense in view of the fact that a purpose of a model is to represent important aspects of reality. If Backlog is a data object then probably a dataState="updated" would be as far a we can go describing it after a token passage.
I'm neither a Scrum nor a BPMN expert. Yet a BPMN model should be "business friendly AND execution ready" and sometimes I see things that a neither or OR. But that's going offtopic now.
<offtopic> This is a problem with the scope of BPMN that it is intended to marry flow charts with execution capabilities (read chapter 7, and especially 7.1 of the spec for more details). Nothing else.
All more advanced topics -functional breakdown, org & data modeling- are explicitely excluded from the scope. Unfortunately the BPMN marketing works well and people see this as an improvement over other notations/frameworks.
If you can live with the BPMN restrictions, it is an interesting modeling notation and I like it. But you shouldn't buy a Mini/Smart car if you intend to transport tons of goods somewhere (to use an external analogy here). </offtopic>
<offtopic> I find it interesting as well, especially when I'm frustrated with workflow limitations of EPC. But there are 4 things that are really off-putting:
1) When I have a problem with EPC I solve it in a matter of minutes by e.g. adding attributes like "MI", "Compensable" etc to functions or make events different types by user-defined attribute with different symbols. That's not the case with BPMN. Even very simple cases require complicated workarround. And that's accompanied by qualms whether it's a violation or not.
2) Every time I make a serious attempt to apply BPMN with required rigour I have many questions that the spec doesn't answer. And I don't remember having such problems with UML which is maintained by the same organisation.
3) I find the capability to model who/of which type/how of equal importance to workflow patterns and quite difficult to live without. Don't really understand why should pool/lanes be so lame while other elements are so sophisticated
4) EA, BPM, SOA etc should be one and the same thing. Aligning business and IT is not achieved by creating more, and in this case, artficial gaps. BPMN makes EA and BPMN two seperate worlds and that's not in the sake of execution. I hear explanation that it is becasue the spec is vendor-led, not user-led. But aren't these vendors interesetd in the EA market?</offtopic>
<offtopic> I agree with your assessment (esp. 4.) and it takes some workaround to show things in BPMN. Maybe you revive Sebastian's idea of BPMN "nonsense" *his words ;-)* and post your experiences/examples in the BPMN group. This will give all of us the chance to learn from each other </offtopic>
hi, just a few thoughts - on the agile horse!
Having grown up in waterfall process structure --
starting always with data modeling ie. resource orientated architecture (ROA)
i am now being lead forward to take up agile with the SOA approach --
i.e. jump in head first before testing the temperature or the depth of the project.
I am all for it however, I am more inclined to believe that a hybrid model between
ROA and SOA would be more appropriate ( see amir glatt's article on sap sdn site)
Sprint 1 in agile to my mind should work out the data model first before proceeding
with prioritising which requirements to implement first.
In terms of BPMN, i expect to see it mature over the next few years.
tx.
my apologies --
i meant to reference the following articles:
The COmmon Reference Architecture (CORA), Part I
Theo Elzinga
virinder
I just uploaded an ARIS Express model to be used as Scrum task board during the sprint phase.
