hi this is karen for marvel your agile evangelist and welcome back to my channel so we are gonna
be talking about a very very controversial topic today and i am so excited about it so
our topic for today is should box be estimated should scrum teams estimate box what do you think
as usual leverage the comment section as i share my own thoughts around this topic please i'm not
saying that it is the fix and final or what i'm saying is set on stone and it's a gospel
how it should be i'm not saying anything like that i'm only saying it with respect
to the result that i have gotten as a result of implementing my own strategy so i am also very
open to hearing what you think please use the comment section share your own opinion
and so that we all can continuously expand our thoughts and expand this agile space now
let's get straight into our topic before we do that if this is your first time here you're
very welcome here we talk about agile project management specifically scrum mastering product
development the agile mindsets the agile ways of living and the beautiful ideal ways of working
so that you stay in sync with what you do here on a weekly basis please turn on the subscription
button down below and the notification bell so you will never miss any of our content and for
our returning subscribers and viewers we love you you appreciate it and thank you for being a part
of our little agile village now let's go straight into the topic should box be estimated well
this topic has been discussed in many communities of practice in the organization by teams
and yet it still stays highly controversial
i hear some people say that bugs should be estimated and their justification for that
is well the team is spending time to do the work to do to resolve the box so who is accounting
for that capacity they have to account for the capacity that they are spending on doing the work
and other people would say that well they are spending time and effort to do this work so they
need to claim some credit for it and that is why they would put some story pointing on it you see
so those are all you know their own opinion which it's okay it's okay now if you ask me
i wouldn't estimate votes i wouldn't and this is my reason why box should not be estimated
as appointed you know bugs should not be pointed and my reason for that is because
where does this box even come from remember that box is usually generated from user stories
from something that didn't go the way it was supposed to go right so you've done a user story
and for some reason box are caught and it's sent back to the team for rework and um remember that
the user story was originally estimated right it was already estimated or story pointed and now
it's been worked it's it's been sent out and then it returns back to the team for rework
and on the other hand remember what is story pointing story pointing is simply
the measure the estimated measure of value to be delivered to the customers right
and um the user stories have already been estimated then this box that your your your your
fixing has already been estimated as part of that user story that the box is being generated from
you see so it means that you are double estimating the work if that's what you're doing if you choose
to it's made box you're double estimating the work and secondly what value does this bring
to the customers directly what real value does this bring to the customers because users story
pointing like i said is just a measure of value to be delivered to the customers and which is
captured in the user stories so this box you are just fixing what you didn't do very well
you see so if you're estimating this this box and claiming credit for it and then um um who
is paying for that who is paying for that that's the question so one of the other reasons why i
would not smear boxes because this is a mindset thing it's a behavioral thing that's how i see
it come to think of it you're cooking right you're cooking your kitchen and you you're progressing at
the end of your your whole cooking thing you don't bother to clean up your kitchen you don't bother
to do anything because you think that because you know that oh maybe you have another person that is
assigned to clean up the kitchen so you will not care on how messed up the kitchen is going to be
you will just mess up everything and leave it there because you know it's not going to be
yours to clean you see is the same approach or the same analogy i'm applying here when team members
are working on the user story just the thought of them knowing that if the work is not done in high
quality it's going to come back to them as rework and there will be the one to pay for that nobody
is paying for that you see that alone will change their behavior it will influence their behavior
to ensure that they are delivering quality to ensure that they are taking all the precautions
they are not skipping steps you see and with that it will reduce the box it will reduce the
number of bucks that that the teams may be getting you see so instead of sitting there and worrying
on whether on how you should be managing bugs which estimating is just part of managing it
why don't you look for a way to eradicate the box or remove them completely you see so same members
having it at the back of your mind that okay um whatever the outcome of this user story would be
it's gonna be on me as a team you see they would pay attention to ensure that they are
not skipping steps they are taking their time and delivering high quality value so that they
would not have books to to rework on you see so i do not think box should be estimated because
the estimate of that work has already been captured in the original user story so box should
not be estimated it means that you're estimating that particular story twice which which was just a
mistake you made because for for whatever cause that was but that has already been captured in
the original user story and you re estimating that ball you are double estimating that work
that's just what you are saying you see all right i'm just gonna use another analogy on
something that happened to me just a few days ago so my car had an issue and i went to the the
the car technician to to check my car and and do whatever fixes they had to do so they charged me
over a thousand three hundred dollars for the car to be fixed and they said oh whatever they have
to put in it is expensive and then with um the labor cost which was okay i made the payment and
they said the car has been fixed i brought the car home and now i'm driving the car two days after
i realized that i still had it still had the same problem it had the same exact problem so i had to
take the car back and when i went back to the the the the you know the car technician they had to
still do it again they had to rework it they fix it and now come to think of it are you saying
that okay if if story pointing is a measure of value to be delivered to the customers
are you saying that this rework that was done was an additional value delivered to me the customer
is that what you're saying if that's what you're saying then yes you should have a point that box
should be estimated but if no additional value was delivered to me rather i was disappointed
because i had to go back there you know and my car didn't do what he was supposed to do and they
first of all charged me very expensive so i was i was disappointed and i saw that i would never
go back to them again for anything else after that i would not i will not use them and that's
really negative feedback going out there you know and it would it would affect their business so
if i i i so now that i took the car back to to their place and they had to rework it
so if they are still um estimating this work putting in story points and and all of that
i'm not getting any additional value from the real work they are doing no they are just fixing
what they didn't do very well originally you see so they are paying for that not me
they are paying for the rework not me so so that is the reason that's just exactly for in the same
light in this whole agile space that's exactly the reason why you should not be estimating bucks
just knowing that um if you don't do this in high quality you will be the one to pay
for it it's gonna come back to you it's gonna um influence your behavior as a team to ensure that
you're taking your time and you're delivering the best quality that you can to your customers
well if it's a situation where again just to be very realistic if it's a situation where
the product itself is highly complex right it's highly complex and then as a team you have you've
had a conversation that okay as we discover you know we find out um new things and it's
gonna be that complex and box may happen right and in that case yes when these things happen
i wouldn't even call those things box i would call them anomalies again that's the topic for another
day those ones are anomaly and it's okay in that case it's it's maybe okay to estimate anomaly
but if they are box i wouldn't estimate box how do i address books the way i would address box is
when i get box again putting in all my best and i get whatever box i'm getting so the way
i would handle box is as a scrum master during a planning phase i'm encouraging my team to reserve
10 of their capacity an average of 10 percent it may range between 10 and 15 depending on
the complexity of their work so they will reserve about 10 percent of their capacity and when they
get bugs and other things unknowns they should use that time inside out of the 10 of that reserve
capacity to resolve that and i would rather track the time the effort spent in finishing this box
or in in fixing the box that's what i'm gonna be tracking i'm gonna be tracking the effort spent
on fixing the box and there is a reason why i'm tracking that the reason why i'm tracking the
effort spent on fixing the box is so that as a team we can clearly see the amount of effort
that is going towards box fixes instead of doing new work instead of creating new functionalities
with that we have a conversation around how can we be better how can we improve our work so that we
don't have to spend all this amount of time just for bug fixes and not doing real work you see so
that is the only reason why i would track capacity on box not so that the team can show that yes we
have been spending our time on this box so we we have good justifications why would not create new
functionalities no that wouldn't be the reason why i'm doing that because that's what teams do
that's what i've noticed on teams they want to claim credit and justify their time spent on on
other things you see i wouldn't do that so to round this topic up the easiest way i like to
look at this thing and to explain it to to to my my mentees or my students is come to think of it
imagine that in an entire sprint right you didn't work on nothing else as a scrum team but bug fixes
the only thing you worked on on that entire sprint was bug fixes
are you gonna be be saying that you're able to deliver some value are you gonna say that oh you
you delivered um 30 story points where you know that you did not create any new functionality
no of course you will not be claiming any credit for it if 100 what you did was just box fixes
your velocity is gonna be zero in that sprint that's just the honest truth your velocity
is going to be zero so that alone tells you that as a team you have to do better
you have to do better again that's my own opinion
and as always i'm very open to hearing what you think please leverage the comment section and
drop your thoughts drop your opinion drop your own experiences so that we all can continuously learn
thank you so much