A bit of practical observations of SCRUM – well, maybe not relating to the whole Framework, but only two of its aspects – the estimation and planning. I will begin with a short SCRUM reminding – well, as we all know, one of the main SCRUM artifacts is Backlog (the list of product backlogs) – this is a list of changes that are to be implemented in the product by the development team (or teams) working on it. The changes (tasks) on this list are discussed by the development team during the meeting called “refinement”, so during the meetings of ordering the list of product backlogs (however we should notice that the “refinement” is described by Srum Guide as the “continuous process”, so the attitude towards the “ordering” can look differently in different teams; in teams that I worked with the meetings were organized once a week to discuss the backlog tasks). So, during the “refinement” the team tries to estimate the amount of work needed to implement tasks (removing the backlogs) written in the Backlog. Of course, the estimates concern the particular tasks, not the whole backlog that can be estimated only… generally (at least in theory). Here the first problem appears: how can we estimate the amount of work needed to implement a particular task?
Of course, there are few approaches (Scrum Guide doesn’t help us in this). In a team that I work with we use the so-called "story points" (SP). The idea of SP is simple, however at the same time it creates the most problems (and provokes many discussions) – I will return to the issue of SP, now let’s look at what is going on later on the SCRUM production conveyor. Based on the estimates made during ordering backlog the team can determine, during another meeting called “sprint planning”, how many of the tasks from the top of the Backlog list, that according to its own priorities a Product Owner sorts, can be executed during the upcoming “sprint” (so the permanent period of tasks implementation). My experiences are limited to the biweekly sprints, but it is obviously a contractual issue – Scrum Guide determines the sprint length to be a month or less.
And this is more or less how it works – after finishing one sprint, another ones are planned and implemented.
One note: I omit here many details and not only – this article does not aim at describing SCRUM as it is, I want to focus only and exclusively on the problem of estimation and planning!
All right – let’s assume that our solution of the first problem (“how to estimate?”) are SP, so it is time for the second problem: the relation of SP to time. The definition of story points (linked in the previous paragraph) contains an important sentence: “Story points do not relate to hours”. It turns out that it is a problematic issue. Let’s imagine a situation where a team received a product backlog and was asked to estimate it (I will shortly remind you that in this article I simplify the SCRUM processes). Let’s assume that the estimations will be made in SP, the team immediately started to work and after the brainstorm it delivered a beautifully estimated backlog (each of the task has assigned a value in SP). Now the team goes to another meeting in order to plan the first sprint. Let’s imagine this very meeting - on one hand we have a beautifully estimated backlog (in SP that is not connected to time), on the other we have Sprint that is determined only with one value – the length of duration, so the time!
How can we connect those two? After all we have to decide on the number of tasks that are to be “taken” into sprint (so to implement them during its time) and our SP does not tell us anything about time (like any other SP). And again – there are at least several solutions to this problem (if not as many as the SCRUM teams), I will focus on two of them.
Romantic love.
In literature I came across a term called „promise”. With this approach we are not concerned with the consequences – we take as much as we think we can bear. It is really a good approach in case of beginner teams or teams that start working on a new project. It gives them a work comfort – after all our sprint backlog (so the task list in sprint) is just a “promise” (pressure connected to the term of implementation practically does not exist)! With such approach the business can try to ensure a minimum of work that has to be done by indicating the sprint goals (the goal of sprint defines tasks that MUST be done in order to complete the sprint successfully). By ordering tasks in sprint backlog according to their importance for the business (so if something is not done, they will be the tasks from the bottom of the list, however those of higher priorities will be placed on the top). The “romantic love” is an approach, let’s say, a little demanding. Planning sprint is quite fast here – we just take a task list from the top of backlog and what will be, will be. Our main problem, so the relation of time to SP, is not so important here. We don’t have to be too much concerned with it and search for ways to “combine” our two worlds (backlog with estimated tasks in SP and sprint, determined only by the duration time), because there is really no need for more scruple verification of our estimations (well, maybe apart from the situations where the task estimated for 1 SP takes the developers about two weeks). OK, going back to our problem, it turns out that we don’t have to be particularly concerned with combining SP with time, according to some it is not needed. Unfortunately, according to me it brings some negative consequences – it makes our project more “chaotic”.
Business commitment
And again – in literature we can notice a term „commitment”, I added only the adjective „business”. It is like the other ends of a scale – “total opposition” to the “romantic love” described in previous paragraph. In the “commitment” all the tasks chosen for sprint backlog can be treated as a sprint goal, it is not necessary to prioritize the tasks (including sprint backlog) – all of them are equally important and failure to complete any of them makes all the sprint failed. In advance I want to draw your attention to the fact that I doubt that such rigorous rules would improve anything – working with such high standard would be very… laborious. According to me, the holy Grail of SCRUM is something between the “romantic love” and “business commitment”. Maybe, the closer we are to the “business commitment”, the further we are to the “romantic love”, the more “advanced” (when it comes to SCRUM) the team is? Perhaps yes – anyway, looking at it from the business point of view, the “business commitment” seems a much more beneficial option. Here the uncertainty of the final “content” of another increase is limited to minimum, even though the negotiations during sprint planning may be more intense and long.
Romantic love or business commitment?
Where is the “switch” that changes our “romantic love” into “business commitment” and other way round? According to me such switches are the sprint planning process and the attitude towards the problem of “mapping” tasks estimated in SP into sprint (determined only by time). What exactly is the process made with, the more we dedicate time to it, the closer we are to the “business commitment” and the bigger are chances to achieve (full) success! It is worth noticing that Scrum Guide determines the duration of the sprint planning to be 8 hours for sprint that lasts a month (the time should be adjusted in case of shorter sprints), so despite the fact that we don’t have detailed information about such meeting, 8 hours may suggest that the creators of SCRUM think about more advanced approach towards this topic than simply choosing the tasks from the backlog ”top” where the sum of SP relates to the current velocity (the average number of SP per sprint) of the team. What is more, the Scrum Guide gives the following advices for planning:
Sprint Planning answers the following:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
The second point is probably the most neglected one when it comes to the approach of “romantic love”. Of course the team may have quite detailed information concerning the (technical) methods of solving different tasks, but the general plan (what, who, when?) will be a pure improvisation.
Mapping
I will shortly remind you what it is that we deal with – we already have the tasks estimated in SP (backlog), now it is time to plan the sprint. Let’s assume that we want to plan our sprint as thoroughly as possible taking care of reaching maximally the “business commitment” (of course choosing one task for a sprint is not a solution following the rule that the underestimation is as bad as the overestimation). Can we help ourselves with any “tool” or can we count only on our experience and knowledge of product? In one of the teams that I worked with, my colleagues used a very interesting method – now I am not able to say if it was (is) an authorial solution or if they used any method (documented and known) practice – if it is the second one and someone could send me the link to any description, please contact me!
The general rule is quite simple, however different teams can have different attitude to details. The basis is the table of team per time (days) of sprint where the columns are the days of sprint and the rows represents particular developers. In such table we can plan who, when and on what should work (the numbers of tasks should be inserted in the table fields at the cut of a row assigned to a given developer with a column assigned to a given day).
My experience shows that using such table makes a huge difference – this is the first verification of our plan! Checking whether generally we have enough resources (time/people) for its implementation. We begin working on our basic problem – to transfer SP into time! Well, all right, but if SP do not contain information about time, how can we then divide them into days in sprint? Probably the only possible solution is to determine the time needed for execution of a given task by the developer that will take care of it – in this way we did this in a team in which I came across this practice. I believe that it is really a good solution. This method can also help us understand why we shouldn’t “combine” time with SP – the same task can be divided into different number of days depending on which developer will work on it – this should be completely natural as well as the fact that the tasks estimated on the same number of SP can be divided into different numbers of days (because they will be executed by different developers – with different experience, occupational record, different knowledge of product, etc…).
Of course – let me clarify – as far as I remember we didn’t try to fill all the days with tasks. In case of coders (people responsible for a code) the endings of sprint remained rather empty, the testers were then usually in a lot of trouble. And when writing “empty” I don’t mean “with legs on desk” and so on – when there is really nothing to do (there is no one to help, all the backlogs are completed), we can always look at backlog and prepare ourselves for another refinement :)
I wrote that this method may differ in details in other teams. Mostly, from my experience, it concerns the same as what to put in the “task table”. I tend to place all kinds of tasks that a team is focused on during sprint – so the development, code review, tests. As far as I remember, in such a form it worked best. Of course, it is possible to mark only the development, without CR and tests (marking tests without determining when the CR has to be done is just a lottery – the rule “start the day from CR” may compensate the lack of CR in our table, however in my case this practice shows that if something is not in the table, then… maybe someone will do it or not :))
Summary
That’s it when it comes to my reflections on estimation and planning – the topic is not so easy. Is it even worth dedicating time for planning? If someone thinks that it is not, he will surely like the Kanban – in SCRUM we cannot escape from planning. Of course, our approach to planning may differ, it may be a not very precise planning or a very detailed one – everything depends on the team, its results, the satisfaction of PO with the results, etc… If everything is good, it will not make sense to increase pressure and try to “move” towards the “commitment”. On the other hand when we see that everything is falling apart – then the pressure on precision may help the team to find second wind. In case of different teams they may try different approaches – there isn’t a golden mean so far :)