WHITEBOARD MANAGING THE BUCKETS TRANSCRIPT

00:00
I'm going to talk about a concept called managing the buckets, which is the agile implementation
methodology, as part of the Anaplan Way. This is a really useful technique that both Anaplan, our
partners and our customers can use to prioritize what you're going to put into all the different releases
that you're going to do. And remember we're talking about releases, short, quick, iterative releases
and managing user stories within the different sprint buckets with the agile methodology.
First off, let me just whiteboard sort of the sprint process and the buckets as we call them, so we can
level set as to what the whole thing looks like. So first off, we've got the business requirements.
These business requirements are actually going to go into user stories. As we know we translate
them into proper user stories and these user stories go into something that I describe as a master
bucket. So when these user stories are created from the business requirements in the master bucket
they go and somehow they're going to be allocated to the different sprints.
So we classically, in most implementations, we have, you know, anywhere from four to five to six
sprints, let's just say its four sprints for this one. Obviously we're going to have our sprint planning
phase. Then we're going to have our first sprint, then we're going to have a sprint review and sprint
plan of course. Then we're going to have sprint two, another sprint review, sprint three, another sprint
review, sprint four and then an all sprint review. So these are the mini buckets if you will, so the
buckets that we're actually going to be fitting user stories in, are going to be sprints one, two, three
and four in this instance or five or six if you have five or six sprints.
So what's the process that we go through? So number one, the first thing we have to do with our
master bucket because this could have 200, 250 different user stories in and sometimes classically, it
will. As a point of note, it doesn't really matter how many major user stories you've got for the first
release. Generally speaking, you have about 75 to a hundred and twenty five user stories that will go
into a release. So first thing is just think about if somebody says that they want 400 user stories in a
release, you've probably got too many user stories, as a general rule of thumb.
But let's just say that we've got those 400 user stories in the master bucket. That's great because that
could serve several releases. First thing you need to do with the customer, is you need to obviously
prioritize these things and you're going to be doing a couple of things. You're going to be doing it
either P1, P2, P3. P1 being the highest priority, have to have it and then you're obviously going to be
prioritizing it by release; release 1, release 2, release 3 etc., etc. Your focus of attention is obviously
on release 1.
First off what you're going to be doing is actually classifying the priorities and the release and then
you're going to have this sprint bucket, as I call it. This sprint bucket is now going to contain the user
stories that you have appropriately classified as P1, P2, P3. Obviously for the release, some of these
things you know are probably their user stories are aspirational, they probably have to go into a
second release and you're probably going to know that. So just focus on the first release and then
you're going to add from the sprint bucket, you're going to be adding user stories into the relevant
sprints. And we know that the priorities, what the priorities are. We know there are some things that
are probably more complex that we want to put that up to sprint 1. There are some user stories that
are more foundational, so you want to put them up to sprint 1.

03:50
So you'll have an idea of where you want these different, how you want these different sprints to pan
out. What's really important is that you really have sprint 1and sprint 2 really nailed down. Sprint 3
and sprint 4 can be fairly loosy goosey at this point because you're not there. Things can change and
that's the whole point of the methodology. So now what we've got is we've got these user stories in
the appropriate buckets and now we have to do what I call balancing the sprints. Now you've got
several levers that you can use here. You've got a number of user stories, so that's the first lever
you've got. You've got a number of people or resources, so that's the second thing you've got and
you've got a timeline.
So these are the three things that you can have an effect on. When you do the balancing, you're
going to know how many user stories you've got, how many people you've got and what your timeline
is. So you know once you've sized those user stories using the planning poker methodology, you'll
know whether or not they fit into these different sprints. So the first thing you'll know is, "Have I got
enough user stories for the entire sprint range, within these parameters?" If you haven't, there's a
couple of things you can do. Let's say we've got too many user stories, which of course typically is
exactly what happens. So what do I do? Well I can either extend the timeline. I've not know anyone
extend their timeline yet, especially at the start of the project, so that's probably going to be a
nonstarter.
You could potentially add more people but even that at the start of the project is usually fairly
unrealistic, and nine out of ten times, even if a client decides to throw a couple of people at the
project, they're inexperienced and they won't really have too much an effect, especially in the early
sprint. So it's really not something you can take into account. You potentially could add more Anaplan
people but don't forget you've probably signed a customer success, statement of work and, those are
locked in, there's budgets and people are locked in.
What that really leaves you with is user stories. These are the choice points that we're going to give
clients; I mean, these are genuinely choice points. We could add more resource and more cash, we
could extend the timeline, therefore we could execute more user stories but you have to pick one of
those levers to pull and ultimately you have to pick user stories. So then, in order to balance the
bucket, what I'm going to have to do now is I'm going to have to re-prioritize things and there are
some things that are now going to come out of my sprint bucket and into my master bucket, in order
to balance the buckets, okay.
This is a constant process that you're going to be doing with the client. This is a whiteboard that you'll
probably have to constantly sell the client on to get them back to the basics of balancing the buckets.
If you don't balance the buckets up front and you have an unrealistic view of where you're going in the
sprints; you're going to get to around sprint 2 and you're going to realize that you're not going to make
the work in a way you should be going. And you could have ended up with a very poor foundational
prioritization of user stories and you might not know how to get to the end. So this is a really critical
piece that you have to do. As standard, you're going to be balancing the buckets from a holistic
standpoint, right at the start of the sprint planning process and then every single time you do a sprint
review, you're going to retrospectively look at what happened in the sprint. What user stories did
actually get executed? What user stories need to come back into the master bucket? Or back into the
sprint bucket and then re-allocated, re-balanced down the sprints. And you're going to be doing that
at every single review.
When you do an all sprints review, then what you have to do then is you have to say, "Well there are
some things we may have not executed from the sprint bucket and these are going to go back into
the master bucket. They'll be taken into account when you do release 2". It's really important that that
is a constant process that you do and you're having those constant checkpoints with customers, very,
very important. And every single time that a customer, and this will happen, as you're navigating
through the sprint process, what's happening here? Well there are more of these things coming in
and more user stories that are going into the master bucket.

08:00
Here's what you need to avoid, you need to avoid this boomerang effect where basically it starts
suddenly going into some sprints from leftfield. You have to go through the same process, so if you
want something to go into the master bucket, that's fantastic because that's stuff that we can do for
the next releases. If you want that to navigate from the master bucket into the sprint bucket, which is
obviously this sprint bucket for this release, guess what? You're going to go back to your levers,
you're going to go back to some choice points for the customer. It's always a choice point for the
customer, it's not a "no" for the customer, it's a, "What do you want to go in? What do you need to
come out?" How do we balance the resources and these levers as we go down the sprints?
So that's what managing the buckets all about. It's a very useful tool for both us, our partners and our
customers, as I say and it's something that you should really get used to white boarding because it's
going to be something you're going to constantly refer back to, to the customer to make sure they
stay on track and ultimately they're successful for their release.