Sometimes it is fun to have a look on old knowledge from a different point of view! In this case the old knowledge is Scrum-you’re familiar with it, right? The viewpoint i chose today is the good old divide et impera or defeat in detail! As already announced in the first blog post about the roles in Scrum, here is the next part of the mini-series: the Scrum events in the light of divide et impera. Enough chitchat, let’s dive in!
I see you asking “How is the Sprint splitting anything?”. I asked myself too and here it is: by taking always small chunks of functionality, or even better business value, putting them into one Sprint and completing them one by one. Seems too simple, right? And it truly is very basic. When the Product Owner does a good job, the developed items are ordered by the maximum value. Here the divide et impera gives us the power to develop every section of the application only up to the point when another one has bigger value. This is one part of the huge power of Scrum – the biggest customer value wins! So we are dividing the “what” into doable parts while staying able to react very fast and not waste time on finishing unused features!
The Sprint Planning
The first meeting and the starting point of every Sprint is the Sprint Planning. It is there to shape the Sprint Goal and how to achieve it. The Scrum Team makes the very first step on the “how” level. Often this is done in two steps: looking for possible ways to achieve and than deciding which way to choose and clear the way further.
Another way this meeting divides and rules is by splitting and sorting: if a Product Backlog Item is too big for one Sprint, it is divided into several smaller ones until something fits in. If a Product Backlog Item is to expensive at all, it gets out of the Product Backlog. Hopefully!
The Daily Scrum
In this very effective meeting the Development Team goes through “how” questions of the most important Sprint Backlog Item. The team focuses on how to reach the given Sprint Goal as best and fast as possible. This can mean to decide who does what till the next day. Who will check which possible prototype idea or who will implement what part (maybe in pair programming with who). We have a further division of the how in a more detailed granularity.
The Sprint Review
In the Sprint Review the whole Scrum team looks at “what have we done?”. It is the counterpart for the Sprint Planning-here we look backwards on what was finished. If the Product Backlog Item was only a part of something, here is the first chance to decide, if we adjust this part, go further on the way or spend time and energy in another feature set.
The Sprint Retrospective
The place to look at the “how we are working” is the Sprint Retrospective. Here is the division: in the Sprint Review we looked at the “what was done”. By this segregation of concerns it is assured, that we have a focus on reaching the goals and improving always over time. So we work to reach our business goals and assure to be or become more agile/flexible/professional/whatever our market needs. This Janus-faced character is a wondrous feature of Scrum.
So we’ve seen, that the Scrum meetings are full of dividing and ruling on different stages and at different times. On an abstract point of view there is no need for breaking things more down than it is done in Scrum. If its done right ;)!
What are your thoughts on the Scrum events in general and in this point of view? Do you have something else you want to read about? Would you like to look from another perspective or do you want to see an other part of Scrum analyzed? Did you liked this blog post? Let the world know it and leave a comment!
Thanks for reading and sharing 🙂 i hope you liked it!