Tracking actual efforts for unexpected tasks

[Yuriy Mann]

Hi All.

Please consider the following hypothetical situation:

A team is working according to Scrum, somewhere in the middle of a
sprint.

Now something happens in the middle of a workday that distracts a team
member from the tasks he/she planned for this day, like:

- Failure in some server software (and our team member is responsible
for technical support of this software)
- Problems with electricity supply or local network that prevent
people from continuing their work
- Sickness that makes him spend the rest of the day at home

Let's say the problem is solved the same day, and is no longer
considered in the plans at the next daily meeting.

Now, the question is: is there a sense to track the time spent for
such an unexpected issue in the sprint backlog? If not in the backlog,
then where?

IMHO what it will actually mean: actual efforts tracking in terms of
ordinay project management. The purpose may be to have an ability
later to analyse the passed sprint in details (?)

One of the solutions (offered to me by Tim Yevgrashin) is to put it on
the sprint backlog specifying actual time spent as though the plans
for the day when the thing happened.
But then we will probably need to differentiate tasks in the sprint
backlog to those having been actually planned and those having been
added there post-factum.

Any suggestions/comments based on your experience?

[Michael Vizdos]

Track time remaining. That is all. Do not "over engineer" a solution :).

Review:

http://www.implementingscrum.com/cartoons/implementingscrum-20061226.html

- mike
www.michaelvizdos.com
www.implementingscrum.com

[Alexey Krivitsky]

Michael was faster than me :)

Yuriy,

Ideally you should NOT bother of the spent time as a measure of the
team's progress. The good-enough metric of the
where-are-we-in-the-sprint status is the sum of remained times of each
of the items on the sprint backlog. It gives you how far/close you're
from 0 - "done" state.

For the long term planning spent time also can be avoided and easily
substituted with velocity metrics meaning how many points the team can
do during a fixed period of time

So why you need to track the time spent?

// Alexey

[Yuriy Mann]

Well, not that I do _need_ to track actual time. More than that, we
did not do it in my previous projects with this company until now.

But we've just started our first sprint, and I'm trying to clear up
any uncertainties about common practices for Scrum.

Regarding actual time tracking. It was actually idea of my Danish co-
worker, who is my direct manager in the organizational structure and
the only person in the company who attended a CSM training. So even
considering that I don't like it I have either to understand and
accept it or to come back with a reasonalbe explanation why it's
wrong.

And how I understood his idea (though he was not sure about this too
and he is still learning along with me): in order to fulfill one of
scrum principles, "keep everything visible", we need some mechanism to
assess at a sprint review meeting what we did not take into account
(but should have taken) when had planned the sprint.

A rough example: if we estimate 10% of time to be spent for urgent
support of previous products and 5% - for illnesses, how will we know
afterwords how much time was actually spent, at least as a statistical
metrics? Or suppose we had forgotten to take into account hardware
failures that took 15% of people's time to fix. Should we register
somewhere the time spent for the fixing, so as to analyse it later?

On Mar 21, 3:33 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> Michael was faster than me :)
>
> Yuriy,
>
> Ideally you should NOT bother of the spent time as a measure of the
> team's progress. The good-enough metric of the
> where-are-we-in-the-sprint status is the sum of remained times of each
> of the items on the sprint backlog. It gives you how far/close you're
> from 0 - "done" state.
>
> For the long term planning spent time also can be avoided and easily
> substituted with velocity metrics meaning how many points the team can
> do during a fixed period of time
>
> So why you need to track the time spent?
>
> // Alexey
>

> On 3/21/07, Michael Vizdos <mviz...@gmail.com> wrote:
>
>
>
>
>
> > Track time remaining. That is all. Do not "over engineer" a solution :).
>
> > Review:
>

> >http://www.implementingscrum.com/cartoons/implementingscrum-20061226....
>
> > - mike
> > www.michaelvizdos.com
> > www.implementingscrum.com

> > > Any suggestions/comments based on your experience?- Hide quoted text -
>
> - Show quoted text -

[Alexey Krivitsky]

Yuriy.

I do it the same way:
- we estimate roughly the features (call this giving points) before
planning them into sprins, the more you can estimate in advance - we
estimated all known features by the beginning of the project and keep
estimating them as they appear
- after a sprint is over, I count the points of all the features that
were 100% done by the team in a sprint
- having this number (call it velocity) I can predict roughly how much
sprints it will
take us to finish the backlog of its part

this is how we achieve visibility in long term
it doesn't matter if we had hardware failures, illnesses, whatever,
the velocity is an integral metric.

watching dynamics of velocity from sprint to sprint youк team can get
some ideas of whether they are doing better/worse

-----

as for short term visibility - inside sprints, we use:
- time remained
- feature count done vs. remained

On 3/21/07, Yuriy Mann <yury...@gmail.com> wrote:
>

[Michael Vizdos]

The "transparency" comes during the time you spend with the team and
the Product Owner during the Sprint. There should be no surprises at
the end of the Sprint.

And I ask the next question seriously, with no malice intended:

"Who cares or looks at metrics?"

At the end of the Sprint, you should ideally have a potentially
shippable product that the Product Owner and Team is proud to show
off. So what if your original estimates are wrong; you need to live
with the fact that estimates are usually wrong (smile).

If anything, use the time during the Retrospective (when the team is
alone with no other stakeholders) to internally examine how the team
can get better at it. This is something the team must decide and not
be pushed on from the Chickens!

Hope this makes sense. I will clarify more if needed.

- mike

On 3/21/07, Yuriy Mann <yury...@gmail.com> wrote:
>

[Artem Marchenko]

To me all these metrics are good as long as the team itself is going
to use them.
It is neither a Scrum Master's responsibility, nor the Product Owner's
to track and react on the internal team stuff. Certainly Scrum Master
can propose some metrics, but it is up to the team to take them or
not.

Unfortunately, the externally enforced metrics tend to break trust
level, usually can easily be gamed and are rarely worth their value.
In your rough example if metric was forced to be used by a boss, you
could hardly expect the team to be committed to the actions based on
it. However, if team itself feels that it purely estimates the
maintenance efforts, it might be a good idea to propose tracking the
maintenance time. If it was the team decision, it might work; if it
was the externally proposed decision, it probably won't.

Best regards,
Artem.

[Tim Yevgrashyn]

Hello All.

 

Yuri mentioned me in his post, so I'd like to explain the advice I tried to give him ;-)

 

I used two statements about Sprint Backlog, these I have heard from CSM or read somewhere:

 

* The Sprint Backlog has to display all "life" of the team during the Sprint.

I.e. we need to put as Sprint Backlog Items all development and non-development activities. For example, planing meetings - they will "eat" our time, but if we don't expect them we will wonder why wee failed the sprint and only one day missed - that day was spent for the meeting ;-)

 

* The SCRUM Team maintains the Sprint Backlog and is able to add or remove items/tasks if needed for achieving the Sprint Goal.

So, if one day we discover that yesterday one of guys developed a subtask that appeared unexpectedly, we have to add this subtask for that day. But today it is closed/resolved, so the remain estimation is 0. I.e. we have +1d at yesterday and 0 today. The Burndown Chart will reflect this change and show us how much remain time do we have today.

 

I completely agree with Mike and I personaly always repeat that we measure "remain time" only - we are goal oriented and we don't care about spent time practices. Unlesss they are part of company's administration approach that has nothing to do with SCRUM.

And yes - "velocity" helps to make general estimation when the product will be done. This is one of core Product Owner's technics/approaches and again, has nothing to do with spent time.

 

 

On 3/21/07, Michael Vizdos <mvi...@gmail.com> wrote:

[Yuriy Mann]

"But today it is closed/resolved, so the remain estimation is 0. I.e.
we have +1d at yesterday and 0 today"

To Tim: I still think this has (almost) no difference from spent time
tracking, just another point of view.

> On 3/21/07, Michael Vizdos <mviz...@gmail.com> wrote:
>
>
>
>
>
>
>
> > The "transparency" comes during the time you spend with the team and
> > the Product Owner during the Sprint. There should be no surprises at
> > the end of the Sprint.
>
> > And I ask the next question seriously, with no malice intended:
>
> > "Who cares or looks at metrics?"
>
> > At the end of the Sprint, you should ideally have a potentially
> > shippable product that the Product Owner and Team is proud to show
> > off. So what if your original estimates are wrong; you need to live
> > with the fact that estimates are usually wrong (smile).
>
> > If anything, use the time during the Retrospective (when the team is
> > alone with no other stakeholders) to internally examine how the team
> > can get better at it. This is something the team must decide and not
> > be pushed on from the Chickens!
>
> > Hope this makes sense. I will clarify more if needed.
>
> > - mike
>

> --
> With best regards,
> Tim Yevgrashyn- Hide quoted text -

[Vasyl Keretsman]

Hi!

> And how I understood his idea (though he was not sure about this too
> and he is still learning along with me): in order to fulfill one of
> scrum principles, "keep everything visible", we need some mechanism to
> assess at a sprint review meeting what we did not take into account
> (but should have taken) when had planned the sprint.

You cannot predict everything that might happend during a sprint,
espesially hardware crash or illness unless it constantly happens in
your team. If such issues happend and you are almost sure that Spring
backlog won't be completed you have to reduce the scope.
In my opinion, as far as sprint backlog is subset of product backlog,
which includes only business value items, it shouldn't include
impediments.

I believe that it doesn't conflict with "keep everything visible" as
all these unexpected impediments should be analyzed and discussed on a
sprint retrospection meeting and written down in order to check what
has been improved on the next sprint review.

> A rough example: if we estimate 10% of time to be spent for urgent
> support of previous products and 5% - for illnesses, how will we know
> afterwords how much time was actually spent, at least as a statistical
> metrics? Or suppose we had forgotten to take into account hardware
> failures that took 15% of people's time to fix. Should we register
> somewhere the time spent for the fixing, so as to analyse it later?

In our team we register only the time related to the stories in the
backlog. Depending on the story it may be time spent with product
owner to clarify the story, environment setup, implementation and
getting story ready for acceptance in case of bugs. If something is
going wrong the burn-down chart will show you that.
On the sprint planning meeting each team member mentions his/her own
rough time(availability) for the upcoming sprint, but we do not
reserve common time for possible hardware crash or illness and do not
keep track for it. For exapmle, each of our team members attends
english classes. Time for it is constant - 3 hours per week. We do not
keep track of this time in a sprint backlog. Each team member
substract it from his sprint availability time.

--Vasya

[alexeyk...@gmail.com]

Artem

I agree on this 100%.
I think Ken introduced burndown chart as a metric that is easy to
start with and they focuses on visibility,
but it is the team that should feel the need in having the visibility
increased.

If a team uses short iterations and don't lose focus and feeling of
the sprint goal and status - no metrics are required probably.

// Alexey

On Mar 21, 6:22 pm, "Artem Marchenko" <artem.marche...@gmail.com>
wrote:

[Tim Yevgrashyn]

Alexey

 

I think Chart needed not only for the team ;-)

 

SCRUM promotes visibility of the process for product people too. I think Burndown concept is much more visible than any Gantt-charts and other "standard" diagrams. I expect team is responsible for updating it's actual status in order to maintain trust with external organization. Otherwise, "chickens" will prevent them from normal work by asking "what's going on" and "when my feature will be done" :-)
 

IMO, team has to clearly understand that they are "set free to perform sprint" only under condition that their work is transparent. And before/after internal daily meeting (where they "synchronize" their work in team) they have to update the status.

 

Of course they don't need to promote it, send reports and etc. In worst case ScrumMaster will do that ;-)
 

[alexeyk...@gmail.com]

Hi Tim,

I have a bit different point of view on this topic. Let me share:
No charts can build trust between the team and the customers. It is
only the working product that can.
So the presence of the charts that are demonstrated to the customers
have quite low value. Being a product owner now - I don't believe in
anything but the working features. Although I am not saying that the
charts are bad or irrelevant or not needed at all. Just you cannot
probably build trust on them, They are just supporting material.

So from my point of view the sprint's-whatever-charts or any other
information radiators are useful only for the team members themselves
as long as they
help them stay focused on the sprint goal and commitments.

The release charts - are different thing, they are the main tool of
the customers of steering the project (teams also welcome this info)

On Mar 23, 6:45 pm, "Tim Yevgrashyn" <yevgras...@gmail.com> wrote:
> Alexey
>
> I think Chart needed not only for the team ;-)
>
> SCRUM promotes visibility of the process for product people too. I think
> Burndown concept is much more visible than any Gantt-charts and other
> "standard" diagrams. I expect team is responsible for updating it's actual
> status in order to maintain trust with external organization. Otherwise,
> "chickens" will prevent them from normal work by asking "what's going on"
> and "when my feature will be done" :-)
>
> IMO, team has to clearly understand that they are "set free to perform
> sprint" only under condition that their work is transparent. And
> before/after internal daily meeting (where they "synchronize" their work in
> team) they have to update the status.
>
> Of course they don't need to promote it, send reports and etc. In worst case
> ScrumMaster will do that ;-)
>

[Artem Marchenko]

Well, I would look at it from a bit different perspective. Release
burndown chart is indeed for the customer, and all the in-sprint stuff
including the sprint burndown is indeed for the team. However, this in-
sprint stuff CAN be used for communicating with the product owner.

For example, when people see they are unable to implement the work
they committed to and need to throw some product backlog items out of
the sprint, team can use the sprint burndown to illustrate the
situation. Certainly, it requires some level of trust to be reached.
Also having a steadily declining public sprint burndown chart might
help the product owner and the actual customers feel more safe about
the project progress. AFAIK, these use cases are quite frequent.

All the other in-sprint artifacts can also be used to aid the
communication between the PO, customers and the team. Up to the point
when continuous integration acceptance testing results can be
commented by the real customer via the web - e.g. to clarify if the
acceptance test was a bit misunderstood and should be re-tuned.

To summarize my point: Release burndown and product backlog MUST be
used for communicating with the PO/customers, sprint burndown/backlog
CAN and USUALLY ARE used for communicating with the PO/customers,
everything else CAN be used if team and PO find it useful. It's almost
completely up to the PO-team discussion/agreement, Scrum Master to
facilitate - it's all about "People and interactions after processes
and tools" :)

Best regards,
Artem.

[Alexey Krivitsky]

sure, Artem, I agree:
everything is useful as soon as it facilitates in sharing information
and doesn't hide the reality.

[Alexander Aizikovsky]

On Mar 26, 6:52 am, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> everything is useful as soon as it facilitates in sharing information
> and doesn't hide the reality.

And does not take much time ;)

[Alexey Krivitsky]

> > everything is useful as soon as it facilitates in sharing information
> > and doesn't hide the reality.
> And does not take much time ;)

and people like it :)

[Tim Yevgrashyn]

Thanks to Artem for support. I have almost the same POV.

 

It is not enough to be agile and "absolutely free". Every "freedom" needs control and in this case PO will need such "monitoring" tool. Especially if you want to change scope of the Sprint ;-)

And making all issues/problems visible is one more way to establish trust with ProductOwner and others.

 

So, yes, keep it simple, spent as less time as possible for mainatainance of the list, but do update everyday and make visible for PO and other "chickens".