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?
> 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?
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:
> On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > 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?
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:
> 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 :).
> > On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > > 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?- Hide quoted text -
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 <yurym...@gmail.com> wrote:
> 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 :).
> > > On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > > > 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?- Hide quoted text -
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 <yurym...@gmail.com> wrote:
> 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 :).
> > > On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > > > 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?- Hide quoted text -
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.
On 21 мар, 16:33, "Yuriy Mann" <yurym...@gmail.com> wrote:
> 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?
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 <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
> On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > 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 :).
> > > > On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > > > > 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?- Hide quoted > text -
> 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 <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
> > On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > > 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 :).
> > > > > On 3/21/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > > > > > 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?- Hide quoted > > text -
> > > > - Show quoted text -
> -- > With best regards, > Tim Yevgrashyn- Hide quoted text -
> 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.
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:
> 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.
> On 21 мар, 16:33, "Yuriy Mann" <yurym...@gmail.com> wrote:
> > 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?
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 ;-)
On 3/23/07, alexeykrivit...@gmail.com <alexeykrivit...@gmail.com> wrote:
> 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: > > 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.
> > On 21 мар, 16:33, "Yuriy Mann" <yurym...@gmail.com> wrote:
> > > 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?
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:
> 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 ;-)
> On 3/23/07, alexeykrivit...@gmail.com <alexeykrivit...@gmail.com> wrote:
> > 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: > > > 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.
> > > On 21 мар, 16:33, "Yuriy Mann" <yurym...@gmail.com> wrote:
> > > > 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?
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.
On Mar 26, 2:00 pm, alexeykrivit...@gmail.com wrote:
> 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 ;-)
> > On 3/23/07, alexeykrivit...@gmail.com <alexeykrivit...@gmail.com> wrote:
> > > 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: > > > > 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.
> > > > On 21 мар, 16:33, "Yuriy Mann" <yurym...@gmail.com> wrote:
> > > > > 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?
> 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.
> On Mar 26, 2:00 pm, alexeykrivit...@gmail.com wrote: > > 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 ;-)
> > > On 3/23/07, alexeykrivit...@gmail.com <alexeykrivit...@gmail.com> wrote:
> > > > 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: > > > > > 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.
> > > > > On 21 мар, 16:33, "Yuriy Mann" <yurym...@gmail.com> wrote:
> > > > > > 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?
> > > -- > > > With best regards, > > > 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".
On 3/26/07, 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 ;) > and people like it :)
