Claude Aubry
Transcript (Translated)
Here we go, here we go. And it's a pleasure to speak after Laurent. And by the way, we will start again at Agile Grenoble in the same order in a month and a half, in November. Usually, when I do presentations, I often include scrums.
I often use the Stade Toulousain team. Here, I always have something that is from the region, it's always around Toulouse. So you may have recognized the Canal du Midi. It's the Canal du Midi.
We're talking about flow today, so water. And a canal, the Canal du Midi, here we are at the Sanglier lock.
So, imagine Scrum, with boats arriving, meaning the locks will open at fixed times.
There is a very strong sense of rhythm. And then, you have a fixed duration to reach the next reach, where the next lock is. So here, after the Sanglier lock, we should see the Gardouche lock. And so, there is another one before. So, we would also need to reach Orfix. There is a very strong sense of rhythm.
So we will see how Kanban, as just presented to you, can help smooth out the traffic a bit. For the Canal du Midi, if we wait for a fixed time, for example, every hour to open the locks, what will happen?
Will there be many boats? It depends on the periods. There are no more barges now, it's pleasure boats.
There can be times when there will be a lot of people, but most of the time, there won't be many. To try to have something more fluid, that is, compared to a Scrum rhythm,
not too many queues, so boats waiting, not too much starvation, we would open the lock even if there is no one. So we will try to smooth all this out.
I am Claude Aubry.
I do a lot of Scrum. In fact, this is my second life. In my first life, I did development, project management. I even worked on something that David Anderson mentioned earlier, the RUP.
All that is in the past.
So, agility and mainly Scrum.
I wrote a book on Scrum. We are on the third edition. And this copy here, offered by Dunod editions, will be won tonight by those who stay and play games.
So I do coaching, or what is now called agile coaching, training, support, especially in Toulouse, in rather industrial, rather large and industrial companies. So it's a bit of that experience that I'm going to talk to you about.
So we are fully entering what was presented, like process improvement in banking. So here, I put myself in the context where Scrum is already being used, in a context, I would say, quite classic for Scrum. A team, so a normal-sized team, sprints, well, sprints that are rather long compared to the average, this is a bit related to the industrial context I mentioned,
where there are things to do, so what we call a scope that is still quite well defined at the beginning, so sometimes even... We have specification documents that exist beforehand. A release of a few months, so 4 to 6 months, with sprints of 3 to 4 weeks. That will give us 3, 4, 5 in the release. And then a deployment that is done at the end of the release.
Do you practice Scrum here? So those who know, already practice Scrum? A good half, a little more, okay. So the beginning of my presentation will recall some Scrum principles to go a little further than what Laurent told us in the presentation. We will start with the presentation of the boards. So I will show you many boards and many post-its. Well, but I still start with old Scrum.
Already old. Scrum, you have surely seen this diagram, if you look, Mike Cohn's diagram. So, this dates back to about 2005. I had translated it at the time. So, this diagram that presents Scrum in a very simple, even simplistic way. So, it's good, there is a backlog. We will talk a lot about backlog today. We see a large product backlog, and then what we call a sprint backlog. So I say 2005, but if we look on the Scrum Alliance website, we still see this, I just checked, we still see a diagram like this, which looks quite similar. There is just one thing in the middle, between the product backlog and the sprint backlog, we have put, well, there are still things to do here, to start the sprint, we say, oh yes, we take things from the backlog and then we go, well, maybe there are things to do, through sprint planning. But I still start from this principle. And so why am I talking about Kanbanizing Scrum, adding Kanban to existing Scrum?
Scrum has successes, it's not bad, it's even good, but in various contexts, and even in the contexts I mentioned, we see things that are a bit annoying. So we see, for example, multitasking. The Scrum rule is to say that we are not disturbed during the sprint. So the entire time period will not be disturbed. So if there are events outside, customers who want something, support that wants to react, the strict Scrum rule says to wait for the next sprint. There are cases where this is not tenable. So we need to imagine solutions for this. What we also sometimes notice is the difficulty in finishing things at the end of the sprint. That is, we start a number of elements. The vocabulary I use is stories to say that in the backlog, we will put stories. I will come back to this notion.
We start things, we have trouble finishing them. This may be one of the reasons, perhaps because at the beginning of the sprint, it is not well known. That is, the team will work on pieces, but they don't know them that well. It's a bit related to what we call the backlog. Ah, it's in the backlog. That's good, let's go. But what's in it? Exactly. And then, especially when we mainly have boards at the team level, what we call scrum boards, task boards, stakeholders, all our stakeholders, have trouble knowing exactly where we are in the progress of the product.
I say well that the large backlog, like the large specification, constitutes stock. I did a survey on my blog, I think last year, on backlog sizes. Backlog sizes, I wondered how many elements there were in the backlog. There were varied responses, but we had backlogs with more than a hundred elements. I don't know if among you, there are those who do Scrum. Do you have backlogs with more than 100 elements in them? Are there any? Yes, there are a few. More than 200? Yes, there are some too. Okay. More than 50? For those who do for others, yes. Okay. There you go, so there are a lot of elements in it. So this constitutes stock. Well, we saw that stock, we can quickly say it's bad, we'll try to reduce it.
So, you see the Kanban principles for the third time. So, this is what David presented and what Laurent took up. So, I will also stop my presentation at the first four, trying to see how, starting from Scrum, we can work on the first four principles. So the visual aspect obviously already exists in Scrum, what we introduce is the limitation of work to finish, WIP in English or what I call TAF, flow management, and making things explicit. So visualizing, if we go back to our MyCone diagram, what we most often see is still the Scrum board, the task board here. The Scrum board. And often, visually, that's all there is. The rest is done a bit as usual. So this corresponds to what I call a bit of the vroom cycle, in fact. The vroom cycle is saying we do Scrum for the really what we call the dev part, but before that we do things a bit as usual, then after we'll do deployment or integration a bit as usual. So we'll try to see how to go further. So a typical Scrum board, I would say, looks like this, it has columns,
columns where we will put the tasks, the pieces of work, and then a fourth column on the left. where we will put the items to do, we will talk about stories, stories to do and tasks. Do your boards look like this?
Are there more columns than that?
Sometimes, yes.
A typical board is this. So what sometimes happens is that the stories, even though we have a coach, a scrum master, the stories, the tasks, they move, but at the end of the sprint, we realize that in the end, there are quite a few stories that are not finished. Since I remind you, the sprint is a period of time, we stop. Always at the fixed date.
So some, seeing this, think, well, including the difficulty in testing. Why doesn't it finish? Often, it's because we may have a product owner who is not available, or we have
people who have done Scrum essentially on the developer side, the developers work and say, oh well, no, it's not us who do the tests, it's maybe the product owner, or even people outside the team. So, to see this, because it's a problem, we will add a column to test. And then we will say, so, product owner, you were able to verify your rules and everything.
So this may be Kanban, but I find that it's not Scrum. So I am absolutely opposed to adding columns if we want to continue doing Scrum.
Extra columns are not necessary. So we will see why. So often we see, we say, ah Scrum is a bit rigid, we'll add, we'll switch to Kanban, so let's add columns.
It's completely understandable to add columns when you have a process that corresponds to that. When we want to stay in Scrum, we probably don't need to add columns. That's what we'll see by asking ourselves a few questions. Another way to avoid columns is to remove them.
After all, the columns, the post-its, they can fall, they don't hold well. And then, we don't see the stock in the columns well, it's underneath. When you see a board, often, if there's a lot of stock, it goes underneath, it goes so low that you don't see it. So, what I propose is not to make columns, but to make bins. So, it's a bit of a nod to the word backlog, in fact. But making bins allows... First, when stories are finished, the other post-its, they go down by themselves. Almost.
So, bins. Bins. for our backlog. So we'll start with the sprint bin, so I'll come back to that quickly. A sprint bin, we have our four columns, the stories, the tasks next to them which are here. And when the sprint starts, at the beginning of the sprint, we have something that looks like this. That is, we have our stories and then we have identified the small pieces of work that are here, which are ready to start for the sprint.
So at the beginning, we have all this.
Do you agree?
Well, all this, we can see it like this, we can already say, there are a lot of things, and we won't work on all this at once, there is still stock here. There is stock. So, how to move forward on this? The sprint still has flow, that is, there are... In the team, we take tasks, we start them, we finish them, they move to the right column.
So, the first thing to do, the first visual principle, that's visual, it's good. The second is to say limit work in progress. So limiting work in progress means that there are tasks, we can put a limit on the tasks. To prevent people from starting too many tasks and not finishing them, we will limit the work.
We have this limit that has been added here. Well, we quickly realize. It's maybe a first approach, but it doesn't go very far. It still doesn't prevent starting tasks on different stories. And ultimately, the goal when doing a sprint in Scrum is not to finish tasks, it's to finish things that bring value. So it's rather, what counts is finishing the stories. it's finishing the stories. So finishing the stories, how to do it? This immediately highlights the notion of how the team will work on what needs to be done. On what needs to be done, we will take... Stories to do, we may have, it's not essential by the way, it's not mandatory to even go through the tasks, we have tasks, how to organize the work within the team.
So this is what we call swarming, a concept that comes from Kanban. What's the principle? You have stories in the sprint. So an average sprint in Scrum, with what I said at the beginning, a team of 5 to 9 people, 3-week sprints, a team does about ten stories per sprint. tens, maybe a bit more sometimes, but that gives an idea. A team of 7 people, person, story, how we organize to do the work. So the principle of swarming is to have the best possible tactic for this.
What do we do? So at the extreme, we could say, each developer, each developer, even if they seem to be coding, takes all the activities that are necessary to finish the story. So we could say, each developer takes a story, What I said at the beginning, a team of 5 to 9 people, 3-week sprints, a team completes about ten stories per sprint. Tens, maybe a bit more sometimes, but that gives an idea. A team of 7 people, 10 stories, how do we organize to get the work done. So the principle of the major trial is to have the best possible tactic for this. What do we do? So, at the extreme, we could say, each developer—each developer, in the broad sense, even if they appear to be coding—takes on all the activities necessary to finish the story. So we could say, each developer takes one story,
They work on one story. At the other extreme, we could say, all the developers work on one story.
And then when they finish, they move on to the second one.
What seems best to you?
What do you usually do? In Scrum. Don’t you handle it? Do people take the tasks?
How?
Two developers per story.
Two developers per story, okay. Is that a rule you have?
No, we don’t have any more than that.
Okay, okay. Well, there you go, the idea of the major trial. So, we notice that in software development, the ideal would obviously be to have one story, everyone works on it, we finish it, and then move on to the next one. That’s the pattern: we do one thing at a time, and when we’re done, we move on to the next. It’s really, we don’t have any... Downtime, not too much multitasking, so that’s good. We notice that in our fields, it’s still difficult, and we tend to have a number of developers per story that can vary—depending on the stories, of course—which can be 2, 3, or 4. Generally, beyond that, it’s difficult. So that means if you have a team of 5 developers, you’ll be able to start several... Several stories at the same time, and so the... Two, exactly, so two. If you have two stories starting at the same time, it’s not the same as having a first story with four developers and then a second with two. It varies depending on the type of story. What we can say is that we start working on two stories in parallel and then forbid starting a third while... One of the two isn’t finished. This can be one of the informal rules within the team; some teams work this way. So, developers on one story. So, I drew a stronger line to indicate that there might be someone in the team who will carry the story, the story coordinator, who will work closely with the product owner. This is to have someone responsible who will see it through to the end. This is typically to avoid multitasking. What often happens when we add the test column is that developers finish and then move on to another story. If we test afterward, what will happen? If we find an error, a defect to correct, we’ll have to go back to the story while working on a new one. This typically causes a context switch with multitasking. So, to avoid this, we can say that there is one person who will stay on the story until the end. Who will also push to have it tested right away, to avoid waiting, if necessary. To strongly request a product from another person, and then stay there to correct any defects until the story is finished. So, this is what I noted as a counter, to reference the stories, so SMH, counter. And these counter images are drawings by Patrice, who is the illustrator for my book, and are in the third edition. And so, what’s the point of all this? We could say, using Scrum vocabulary, that the images improve velocity.
So why, beyond the fact that there are bees that sting, it’s by typically reducing multitasking. The goal is to limit context switches and time losses due to these switches as much as possible.
So, SMH. So, if we come to our board with tasks, here’s our Scrum board, it will look like this with these columns. I added a column on the right to indicate that the story is finished. Teams are often bothered if they only have the four columns to show that a story is finished. Some put... A small dot on it, some turn them over, well, everyone... And that’s good, so everyone will invent a way to note it. An even simpler way, if we use bins, is to have something that keeps the finished stories, which can be used for the review.
Okay, so here’s a typical board. We’ll forget about tasks, we can do without tasks. We’ll forget about tasks. If we just look at the stories, here I’ve kept only the yellow sticky notes that correspond to our stories. So, we tell ourselves that what we’ve just seen is that we could already apply a number of practices during the sprint. So, we have our sprint bin with the stories that are put into the sprint at the beginning of the sprint, during planning. So, during planning, what do we do? The team will decide what it will do during the sprint. It takes a certain number of stories—I mentioned the number 10—and then, as it finishes them, it will put them possibly in a sub-bin here to say these are the stories ready for the demo.
So, on the right, we always have the stories that will be deployed for the release. So, I’m talking here about the harvest backlog. And then, we always have our big backlog before that. So, we’ll now try to improve these two aspects.
So, starting with the big backlog. The big backlog at the beginning.
So, there are former students or people who sometimes send me their theses. They write theses or tests on agile methods and then ask me to review them. So recently, Julie sent me her thesis. Julie, I think she’s in a master’s program in computer science and is doing her internship in a large French company. A telecom operator. And so, she sent me—she describes Scrum—she sent me an excerpt from the description of Scrum, particularly about the backlog. So, what do you think? So, PO stands for Product Owner. The Product Owner writes the User Stories, which are the specifications.
Do you agree? No? Well, no. No, it’s all wrong. Let’s say it’s not entirely accurate. So, there are several things that are incorrect.
First, the product owner—well, there’s 'writes.' Writes. The idea is that documents actually cause problems. If we’ve moved to agile user stories, it’s to emphasize direct contact, discussion, conversation, as we’ll see. So, there might be some written things, we shouldn’t say we’re throwing everything out, but nevertheless, it’s not the Product Owner who writes the specifications as before. An analyst could write the aspect. So, the Product Owner doesn’t really write. And it’s not just them who does it, it’s a collective effort. If the team waits for the Product Owner to do all the work, they might be waiting a long time, which will create... So, they might arrive at a sprint with either an insufficient number of things or insufficient quality in the descriptions. So, the team will help, obviously, collective work. So, the team will assist, obviously, collective work. So, we could also say that it's not about the aspect, indeed, that user stories, of which there are obviously some, are not about the aspect.
It's only if we add the tests, everything that goes with it, meaning the acceptance tests, that we can compare to what we had before. And then, we could also add that in the backlog, there may not only be user stories, but that's a debate I won't start here. So Julie, she didn't get it right here, I told her. And so, this is what actually pushes us to have, even if it's no longer a big spec at the beginning, so we have a lot of things. So our initial stock. So let's see how to avoid it. Here, we need to do selective sorting. You have the big backlog, the big black backlog. To move on then... To move on to the small bins, which are more easily managed, we need to sort, do selective sorting. So, what do we sort in our stories?
First, we will note that a story is not a requirement. We classically talk about requirements management, requirements engineering. A story is not a requirement. I'm coming back to this point. There is an important conversational aspect. It's told. You might tell me, he's a bit sleepy, he's not reacting much. But when you do this with clients, with stakeholders, it will discuss, it will discuss much more. So we tell a story rather than exchanging documents. So that's the idea.
Some of you read fairy tales when you were little.
You go with the users, through the Product Owner, to tell the beautiful stories of the product. Where does all this come from? It comes from Extreme Programming, from Ken Beck and Ron Jeffries. I reused a slide from Jeff Patton. Jeff Patton, some of you may know him. He's someone who works a lot in product definition. He doesn't do presentations often, but when he does, they're dense. He just released a presentation called Agile Requirements and Product Management, in which he... He reused this, and I thought, this is exactly what I need here. And on top of that, he draws well. And Aaron Jeffries. So this is what we call, if some of you have taken courses or training on agility, the 3Cs of stories, 3C for card, conversation, and confirmation. And so Jeff Patton presents this by saying that stories, in the end, are a simple life cycle.
We write on a card, so we might say this was a bit prehistoric, do we still really write on cards? First, now it's more like Post-its, well, that works too. But the idea is, we put very simple things here, an idea that will be proposed for the product. So we will give a title here, in fact. After that, we need conversation and then confirmation. So if we look at Jeff Patton's confirmation here, you see there is text, there may be diagrams, we can do UML here. So confirmation. And in the end, when I saw this, I thought, confirmation and conversation, we need them, and we do them several times, it's not done just once, we have a conversation and then we confirm. So confirmation, we also often do it with tests, so we say it's a confirmation that will be done by acceptance tests, and so we often understand that this confirmation takes place at the end of the sprint to say the story is finished.
So in the end, we may need to do these cycles of conversation and confirmation several times. So we will move from the 3Cs to the 5BACs. So, the first cycle of the story, we will do... Conversation, and then we will confirm that... In the end, what will we confirm? We will confirm...
That the story is finally ready. There is a first cycle that will be to say, yes, we discussed between the product owner, the stakeholders, and the development team. And so, following all that, we confirm that the team confirms, since it's the team that will do it, it confirms that the story is ready to start the sprint.
So this is the concept now emphasized in Scrum, which is the definition of ready, ready to start the sprint. And of course, during the sprint, we can continue to discuss, we can possibly add acceptance conditions even during the sprint to confirm at the end of the sprint that the story is finished. So here, from an initial idea that is put on the card, we will need to keep stories ready and stories finished, once the sprint has taken place. So between the two, conversation, we don't just do that, we work. And a bit, during the sprint, obviously, we will work to develop. We will develop the entire story. So develop, code, document, test, all that is part of what we do during the sprint. And then, to finally ensure that the story is ready, there is also a need to work. For the story to be ready, there is a need to work. The term I use is 'cultivate'. In English, the term that has been used until now was 'grooming', 'backlog grooming'. That's the one found in English literature. In the new Scrum Guide, it talks about 'raffinement'. I'll say it in French, 'raffinement', and in English, 'refinement'. So the vocabulary has slightly changed. It's the same idea. We will cultivate the backlog, grow the stories to get them ready. Coding, documenting, testing—all of that is part of what we do during the sprint. And then, ultimately, to ensure the story is ready, there is also work that needs to be done. For the story to be ready, work needs to be done. The term I use is 'cultivating.' In English, the term that has been used until now was 'grooming,' 'backlog grooming.' That’s the one found in English literature. In the new Scrum Guide, it talks about 'refinement.' I’ll say it in French—raffinement—and in English, refinement. So the vocabulary has slightly changed. It’s the same idea. We will cultivate the backlog, grow the stories to ensure they are ready.
And so, from these three Cs, we can have five bins that will collect the stories according to their state. So we realize that this, roughly, is a queue. We saw some of these concepts earlier. This is roughly the input queue. It’s so that users can put...
The ideas they have, and then we have the output queue over there, and in the middle, we also have an input queue. This input queue will allow us to decouple the work, because obviously, we always have sprints here, so the sprint phase here always starts at a fixed time. At a fixed date. So we need to keep the stories that are ready for the sprint in a waiting queue. So, quickly, these detailed concepts. The sandbox is a concept we’ve seen for a long time in Wikipedia. The idea is to deposit ideas there until they are finally accepted. So it’s the place where everyone can put ideas—the product owner, of course, all stakeholders, everyone can propose ideas and put them in the sandbox. It’s rather the product owner who will decide what to do with them, meaning whether this story, this idea, will ultimately be kept for the product or not.
There’s still a conversation I haven’t included on the diagram. But obviously, to do this, they will surely need to dialogue, discuss with those who made the request. A story at the beginning is very light, with little effort put into it; we just need a title and a brief description. Probably, since we’re talking about limits, it’s difficult to limit the size of the input bin because that’s where we have ideas, but what we can do is ensure that the duration of stay isn’t very long—that is, the product owner... With the team, processes the requests quickly to at least know what will be done with them. So here, we can obviously have rejections—that is, we can tell users, no, we’re not keeping your idea, at least not for the current release. The next bin is roughly the old backlog bin, where we will cultivate the stories to grow them. We have our product owner who has ideas; he has planted the little sprouts in the sandbox, and now he will make them grow. He will make them grow until they can be ready for the sprint, until we can implement them in the sprint. So what kind of work is there to do in this cultivation bin? There’s quite a bit of work, actually. In the cultivation bin, we have ideas at the beginning, so we need to make them mature. What do we do? We will add details, but often we have things that are too big, so we will need to break them down into smaller pieces. Since the idea is for a... to be ready, so at the output of this cultivation bin, it must be understandable by the team, and the team must feel that they can finish it in a single sprint. So we will break them down; possibly, we will also estimate—you may know planning poker—planning poker is a conversation. Planning poker is a conversation that serves to estimate, but also to understand, to communicate between the team and the product owner.
So our cultivation bin can contain quite a few stories. We’ll see later how we can further reduce this number. The starting bin is where we put the stories that are ready for the sprint. So they are in the starting blocks. Yes?
I just have a question about the cultivation bin.
Yes.
Should the entire team participate in the maturation and have a few team meetings to finalize the conversation part? Or can we still limit the impact on the team’s workload? Maybe have one person at a time per story, rotating that role a bit. Or is it the third option? Would it rather be the Scrum Master?
Well, it’s up to the teams to choose, actually. So, maybe not the last option, because that doesn’t fall under the Scrum Master’s responsibilities, I would say. The best is to involve...
Wouldn’t that be in the sense of organizing ourselves?
No. The best is to involve the whole team. So, to do this in what we call... I’ll tell you about it later. Backlog reviews where the whole team will participate. But we realize that sometimes it’s not enough to set aside time for this. And so, what we might end up doing is creating what I call discovery stories or analysis stories, which are the work on the cultivation bin. And to make them appear explicitly. That can be taken by someone from the team. So, in addition to the team, it might also be the time to involve stakeholders. We need people outside the team as well.
So the starting bin, the starting block, is the idea of beginning a sprint in good conditions to be ready. So the conditions are decided by the team if the story is ready. So, self-organization—it’s the team that decides if the story is ready. So, they do this based on their own conditions. So, it’s up to each team to define what they expect. So, generally, as a team, we will say that it must be possible to develop it, particularly that there are no dependencies. We mentioned external team dependencies this morning—that’s a problem. If the team starts while depending on other people who are not available, it’s risky. So we will say that the story is not ready in that case. And that it can be finished in the upcoming sprint. I’ll skip the sprint since we’ve already seen it. So ultimately, the results go into a harvest bin. The harvest bin is where we place the finished stories. So when does it finish? Its definitions finish it; it meets its acceptance conditions. Plus some completion criteria, so to distinguish between the two, the acceptance conditions are specific to a story,
we will turn that into tests on the story, so obviously the tests are dependent—each story has different tests—but the completion criteria are quality criteria that can be associated with types of stories, which will be roughly repeated for each story of that type. Particularly for stories with code, we can define, which is what we generally do in the definition of done, what we expect at the end of a sprint. So it’s generally the product owner who says if the story is done and moves it to the harvest bin. And it will stay here until deployment happens, roughly. So, it would be better to do it earlier, since it’s ready, we can say it would be good to deploy faster. So, I’ll come back to that quickly later. So if we look at the life of the story with these five bins, we have a sandbox where everyone proposes ideas. Obviously, ideas are not always accepted. There can be possible rejections from the product owner’s team. And here, it doesn’t seem necessary to have priorities. The items will normally stay for a limited time before they are processed. The cultivation bin, which will actually probably be the largest bin, so here we are in a state where the product owner says, it’s not bad, I’d like us to do it, but it’s not yet feasible by the team. So it will need to be worked on with the meetings we just talked about, possibly estimated, and then we need priorities, since we will seek to work on and break down what is most important, obviously.
The starting backlog to begin the sprint. So here, we can say the team agrees to say, yes, yes, it's good, we can start with this. During the sprint.
A diagram showing that as the life of the backlogs progresses, we will add information to the story. Perhaps initially, when the story is in the sandbox backlog, there is only the name. In the cultivation backlog, we will add things like the template you should know. So we will use the role and then show—generally, I’ve only put two, but there are three sections—so as the action that is taken and then the benefit for the one who triggers the story, in any case for a user.
It is generally in the cultivation backlog that we will estimate in points if we do it. And then we will begin... So for it to enter a starting backlog, you probably need to have a good idea of the completion conditions, which are roughly dependencies either on external components or on people outside the team who will help to... Finish the story.
And then, therefore, type the story, for example, say it's a user story type, there are different types of stories, this one, a user story with code, we have a definition of done for that, and so this definition of done will apply to our story.
So, to further reduce the size of the cultivation backlog, because nevertheless, despite everything I've said, there can still be quite a few elements in it, so what do we do? So, I remind you that we are in the context of a delivery, a release, with several sprints. So, to limit it, we can say that there are probably elements we won't do right away, which are not for the current release but will be for the next one. So here, it is typically the responsibility of the product owner to say, if it's not for right now, there's no need to put it here, we'll put it in another backlog. We don't look at it, the sandbox backlog, the icebox backlog, we freeze all that, we'll take it out when we need it. So this allows us to limit the size of the cultivation backlog and not clutter the team that will work on it with things that are not a priority. They will wait until the end of the release, which could be in a few sprints.
So an icebox backlog will be yet another backlog.
Basically, it's a tool that serves what you surely do and which is called reducing the scope or changing the scope, so descoping the story.
If we look at when decisions are made, with our backlogs, here we really have ideas, the ideas can obviously be rejected.
At what point do we really have a commitment? It's when it enters the sprint, in fact. In the meantime, we still have options. Obviously, if the product owner put it there, it's because they want to have it, but there are many reasons. That mean maybe we won't do it, or we'll do it differently, or we won't do it right away. So we may find stories in the icebox backlog, or even in the trash if we reject them.
So, commitment, commitment, is there really a commitment from the team? It's a debate in the community.
In any case, the commitment that can exist is a commitment. If the stories enter here, we finish them. Maybe we won't finish them in this sprint, even if we hope to, but we will finish them at least in the next one, so we commit to finishing them.
I do not recommend having a commitment on stories when doing a sprint.
So, if you really prefer boards, if you don't like backlogs, we have the same version, the version of what I just presented to you with boards. And once again, all this is an example I'm giving you, which can be used in the contexts I described at the beginning. It's obviously up to you to make your own boards. To add the columns that work well for you in relation to all this.
With these backlogs, we can create a cumulative backlog diagram.
Some may know the cumulative flow diagram. It's a variant of the cumulative flow diagram found in Kanban. Here, doing it on the backlogs. Look at the status either in points or in stories on the backlogs. I put here at each sprint, but ultimately, it's better to do it in a desynchronized way to avoid jolts, because in fact, if we look at how the sprint goes, at the beginning of the sprint, we take everything that is in the starting backlog and put it all in the sprint backlog.
backlog. So the diagram, depending on whether we do it just before or just after, there will be variations and it may be difficult to understand. So maybe it's preferable to do it every week, in fact. This provides additional indications on the state of the backlogs, on possibly the efforts that need to be made. We will also see if there is excessive stock.
excessive. So I quickly come back to stock. In fact, if we look closely at our sprint, there is still some stock, since we kept our sprint planning, and well, when we say at the beginning of the sprint I will do 9, 10 stories, we saw earlier that we might work on 2, 3 stories at the same time, So, way too many, since we won't work on them right away. So, there is still stock. How to limit this stock in the sprint?
So first, we can work on the types of stories, so say that not all stories are of the same nature, which is what Laurent mentioned with the concept of service class, possibly limit and create rows for these different types of stories. But to go further, we can set an explicit limit on the sprint. We saw WIP limits earlier. After all, what are WIP limits? We see that there is no need to have so many stories in the sprint since we only work on two, three, maybe four at the same time. Might as well set this limit here. And so prohibit having more than three stories in our sprint backlog, if we consider that three is the right limit.
Ah, what do we do then with the stories before? This means it still questions the way sprints are done. Sprint planning is adapted, that is, instead of during sprint planning taking all the stories the team will commit to, we say we stop at the limit, there's no need to plan them in detail, to find tasks even, we have time. So we stop at the limit and we'll say if it's 3, we stop at 3. Obviously, we will need to replan these stories during the sprint to agree, to possibly find tasks on them. When to do it? We can say we will do it as soon as a story is finished. As soon as a story is finished, we will do a replanning, we will see the... next story. The best is maybe to wait for the daily meeting.
Meanwhile, if our story is finished, we will help the others, we will wait for the daily meeting, then we will see how we will restart the WIP with a new story after this daily meeting.
So this promotes swarming and obviously the interest is that it avoids blocking, fixing the stories we will work on during the sprint without the possibility of changing.
Or at least, if we do it, it's very disruptive. Here, there is no problem since... The stories are not yet really considered as being in the sprint. So if we go back a bit further, we can say, it's good, we limited the sprint, but our starting backlog, could we not limit it too? So the starting backlog, in any case, all the ready stories, they need to be limited. There's no point in having 50 ready stories, obviously, since we will only work on about 10 in a sprint. So we can say, it's good to have stories for a little more than one sprint, maybe two. So generally, the starting backlog where there are the ready stories, it needs to be limited to 15, 20 stories maximum for a normal sprint. But with this notion of limitation on the sprint, we can go even lower, since it's enough that there are enough stories, to take into account maybe what will happen in a whole sprint. So we can say 3, 6, 9, I don't think I'll do more than 9, stories anyway, generally that's what I do, so there's no need to put more. So we can set an upper limit that decreases. Which decreases the size of this backlog.
But it remains, so we saw how we could trigger here with basically a story finished, which amounts to having a lower limit, by saying each time we get to two, we trigger a new sprint planning which will consist of taking a story that is here to put it here
by... Agreeing on it and breaking it down into tasks, and well here we can also say that there is a lower limit that will trigger cultivation in fact. A lower limit, when there are fewer than three stories for example here, we will trigger work here so that the team can produce stories that are ready
So we have reduced our backlogs. So our cultivation backlog remains. Our cultivation backlog, how to reduce this size? We saw the sandbox backlog, we just saw limiting upstream.
But we can still have quite a few stories in it, since I take the example of 10 or 12 stories per sprint, 5 sprints, that means we could still have 60 stories in the cultivation backlog. Fortunately, we don't break everything down at the beginning, that's not the goal at all, we break it down progressively. So we're going to have large chunks. At the beginning, large chunks, and then only the smaller chunks will be broken down because they are prioritized. We could limit it, in fact, for example, to about fifteen elements; that seems entirely feasible with the numbers I gave earlier. So to go even further, the solution is to actually have a higher level, meaning we have features—features are the largest chunks, essentially. If I take the classic buckets, it's to do, in progress, done. In a sprint, features are chunks that bring significant value and can be deployed. In a sprint, it may not be very useful to work on more than 2 or 3 features at the same time for a team of the size I mentioned earlier. So we will limit the features bucket. too.
The feature decomposition technique will be for another presentation; I’ll skip over it. Just to finish, the big picture allows us to have two-level boards, as we saw earlier—maybe at the product level, here at the team level. And so, with a starting sandbox, the elements are fed into... So if they are large chunks, they go into features, and as soon as a feature moves to in progress, we can break it down here. The rule that can be added is that when working on a feature in a sprint, we will cultivate it beforehand so it’s ready for that sprint. And so, this will be a trigger to break down large stories into smaller stories. And what we deliver at the end are features that constitute fully deliverable, deployable things, which contain a certain number of stories. And so, that’s just to finish. So, if we really want faster deployment, we can say there’s no need to wait. Obviously, the ideal would be not to wait a period of several months to deploy but to deploy as soon as we have things that are deployable because they bring value to users.
There you go, that’s it. The sprint events, so already in a sprint, we have what we call—now it’s called ceremonies—the events: planning, the review, the retrospective, which are already done as usual. So that was a bit of an answer to the question asked earlier: we can do regular backlog reviews to work on and cultivate the backlog. For example, a good way to proceed is to do two hours of backlog grooming or backlog review every week. To go further with what I mentioned, this principle of limitation on the sprint means having a much smaller planning meeting and then doing planning on demand. And similarly, backlog cultivation, instead of doing it at fixed times, we can say we’ll do it on demand when triggered by the lower limit on story prep.
So in conclusion, open the floodgates to make it more fluid, even in the channels.
So I think it’s time to go to lunch.