Re: [Scrum] When to update task status?

[Ron Jeffries]

Hi Bruce,

On May 23, 2013, at 6:19 PM, bru...@gmail.com wrote:

So I wanted to ask if it is really a common practice in Scrum to wait with updates for the standup?
And if yes - what is the reason?

It is quite common. Let me ask you a couple of questions: what might go better if it were updated more frequently? What might go wrong if it was "only" daily?

Ron Jeffries

www.XProgramming.com

If another does not intend offense, it is wrong for me to seek it;

if another does indeed intend offense, it is foolish for me to permit it.

  -- Kelly Easterley

[Alan Dayley]

As Ron said, the habit of updating the tasks only at the stand up is common. I think it is important to think about and discuss the questions that Ron asked. I'll attempt to answer your question as to why this is common.

Here are a few reasons which may be present in any combination. They are of similar flavor:

- The team is accustomed to not actually being together throughout the day so they update the tasks the one time everyone is there so everyone will see it happen.

- Some teams want to be alerted that a task has progressed and feel it is interruptive to do task updates several times throughout the day.

- Many teams do not sit near the physical team board and so miss updates and feel confused when several things have changed since the last time they looked at the board.

- Many teams are not really collaborating but disappear to their desks to do their assigned part and only feel the need to communicate "status" at the daily status meeting now called "Daily Scrum."

- Stories are defined, and tasks to match, in such a way that there is little need to communicate between people throughout the day, except when doing a handoff to the next person.

- The team is separated by time or distance or both, making moments of communication high effort.

- The vision and purpose of the work is poorly defined or is drowning in a stream of multiple projects, inhibiting focus on team communication and motivation.

- The team uses a software tool that doesn't inspire use because it is ugly, hard to use, full of too much data, etc.

- The updates are used for micro-management by someone. No one wants to update information that will then be turned on them painfully.

- etc.

On the other hand, I have seen excellent teams that update the board only once a day out of habit or because the board update is incidental to the amount of communication already happening.

I'd suggest you start with the team you work with and explore some possible root causes for not updating progress more often. It might be something similar to one of my points above or it might be something very surprising. You may also find that solving the problem of updating only once a day is not as important as solving something else.

Alan

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ron Jeffries]

Hi Bruce,

By the time I got to the end of your note, I was confused. I'll leave my comments and questions in, though they may be less than entirely appropriate, as they are intended more to help you think than to be specific suggestions. 

On May 24, 2013, at 4:20 AM, bru...@gmail.com wrote:

Now for the Questions

What might go better if it were updated more frequently?
- Possible to see a real-time picture of the sprint status - not only a daily
- Improved communication through Informative Workspace: Everyone in the team sees what is going on
  (If no one goes to the board during the day something is most likely wrong…)

Are the team in a room together? Are they working together? Perhaps they already know; perhaps they don't need to know.

Why is a "real-time picture" useful, and to whom? If people work their own tasks, or work together, they may already know all the status they need.

What might go wrong if it was "only" daily?

- Two developer may start the same task because it is still open on the board

Has this ever happened?

- No overview about Sprint status changes (e.g. in critical and urgent situations we had)

Explain, please?

- Cant detect harmful multitasking

Is there any? Do you have retrospectives?

- You can not limit Work in Progress (WIP) like in Kanban 

Yes you can. You just don't work beyond your limit. And Kanban doesn't limit work unless people follow the limits, which the board does not force. 

- Boring Standup 
   -> most task are not interesting to everyone - only the overall story status

Perhaps your stories are too big and your tasks are in fact not interesting. 

   -> felt like ages as my distributed team shifted all Jira task
- Standup misused as status meeting 

Does the team mind this? Do they bring it up in retrospectives? 

@Alan
To be honest most of your points seem to me like results of other problems which were not solved.
- Taskboard too far? -> move it
- Team move to their desk and not communicating? -> organize social events, Pair more,...
- Interruptive to update task several times? -> Ask why setting a task to "Progress" and afterwards to "Closed" can be too much work?
etc.

Regarding our team:
Because of the Jira and distributed team issue we agreed to move the tasks during the day and
during the standup we focus on the story status.
This improved the standup meeting and we could not see any harm so far.
People still talk shortly about task they have done - but try to focus on team relevant ones.
But we have now more time to focus on the "whats today" part which we see as an improvement.

I don't understand. I thought your team was NOT updating the board?

Another reason for me is that I would like at some point to introduce WIP limits - which needs this approach in my opinion.
(I have had good experience with this approach and I think it goes very well together with Scrum)

Still I am curious about some of the reasons because maybe I am missing something...

The good reasons would be "because everyone already knows". The bad reasons would be "because no one cares, likely because the information is not useful to them."

Ron Jeffries

www.XProgramming.com

I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

[Yves Hanoulle]

there is also a third way:

people add status post it's to the task post it's

like "DONE" that way they visually update the board, yet the real move is only done at standup when everyone present.

advantage:

-when people update the board, teammembers at that moment present in the team room, see the update.the know this member is available for some work and might ask to pair 

-If someone is ill the next day, we still know what she had finished 

disadvantage:

- people have to get up more and move more

mm, in a world where we already sit too much, this is actually an advantage to me.

- we use more post it's: worse for environment

true, yet the status post it's can be reused

for me this is the best of both world

2013/5/24 <bru...@gmail.com>

Hi,

I have a question regarding when to update tasks in Scrum - or what is the "best practice" most teams follow.

Recently I started as Scrum Master in a bigger company (>30 Scrum teams).
There I encounter something odd (for me): Tasks were only moved at the daily standup.
And I was told that this is pretty common in most Scrum teams

I have been doing agile for a while now (XP + Kanban) but I am new to Scrum.
So for me its strange as up until now I used to see the taskboard as realtime status info.
(And Kanban wouldn't even work that way)

So I wanted to ask if it is really a common practice in Scrum to wait with updates for the standup?
And if yes - what is the reason?

Cheers,
ML

[Alan Dayley]

"@Alan
To be honest most of your points seem to me like results of other problems which were not solved."

Yes, exactly. Rarely is it the case that people don't update task progress because the don't want to update progress or because they are lazy. People don't update progress for some reason. Find that reason and decide if it is important enough to do something about.

Alan

On Fri, May 24, 2013 at 1:20 AM, <bru...@gmail.com> wrote:

Hi,

Thanks for your answers
First let me clarify  
- update task means for me changing status (Todo, Progress,...) - NOT updating remaining work hours!
- Our tasks size is usually less than one day

Now for the Questions

What might go better if it were updated more frequently?

- Possible to see a real-time picture of the sprint status - not only a daily
- Improved communication through Informative Workspace: Everyone in the team sees what is going on

  (If no one goes to the board during the day something is most likely wrong...)

What might go wrong if it was "only" daily?

- Two developer may start the same task because it is still open on the board

- No overview about Sprint status changes (e.g. in critical and urgent situations we had)

- Cant detect harmful multitasking

- You can not limit Work in Progress (WIP) like in Kanban

- Boring Standup
   -> most task are not interesting to everyone - only the overall story status

   -> felt like ages as my distributed team shifted all Jira task
- Standup misused as status meeting

@Alan
To be honest most of your points seem to me like results of other problems which were not solved.
- Taskboard too far? -> move it
- Team move to their desk and not communicating? -> organize social events, Pair more,...
- Interruptive to update task several times? -> Ask why setting a task to "Progress" and afterwards to "Closed" can be too much work?
etc.

Regarding our team:
Because of the Jira and distributed team issue we agreed to move the tasks during the day and
during the standup we focus on the story status.
This improved the standup meeting and we could not see any harm so far.
People still talk shortly about task they have done - but try to focus on team relevant ones.
But we have now more time to focus on the "whats today" part which we see as an improvement.

Another reason for me is that I would like at some point to introduce WIP limits - which needs this approach in my opinion.
(I have had good experience with this approach and I think it goes very well together with Scrum)

Still I am curious about some of the reasons because maybe I am missing something...

Br
ML

[bru...@gmail.com]

Hi,

Thank you all for your support and suggestions.

@Yves:
Thank you for your suggestion.
I think that is a really good solution - if I find out why I should NOT move them during the day.
(Have then to find out how to make this work in Jira ;)

@Alan:
My Team does update the tasks during the day. So no issues here.

@Ron
Thanks for your questions - they got me thinking - as intended :)

I try to clarify:

Mainly I wanted to know the general opinions/reasons behind this- not only for my team.
I have my ideas about this topic - and it says "update!". This is also confirmed by my interpretation of the Scrum guide (which might be wrong) where it is stated:
"The Sprint Backlog is a highly visible, real-time picture of the work..."
However, as I am here to learn I wanted to know why are others doing it different (once a day).

So my questions are:
- Whats the benefit of NOT updating the tasks during the day?
- What are the dangers of updating task during the day?  What might we loose because we do so?
- Why do other teams do it once a day? Habit? Tradition? Reasons?

Some points for me against it so far were:
- People may be confused because the board has changed
- People may not remember what they did (but the task are still there - so unlikely)
- No sense of progress as no moving occurs (for that I have the burndown)

No for my actual situation:
My background:
My Team is distributed: 7 guys here -  5 in one room 2 close in another room, 4 guys in another country - all in one room.
When I started they were 2 teams - but because of specialisation, distribution, and lack of seniors the juniors did not get good support.
Both were working with Jira during standup and I noticed that it was cumbersome.
Actually damn slow compared to my previous experiences (3 years XP, 2 years Kanban - always co-located with physical board).
Task moving took long, lots of scrolling, etc. (You cant beat a physical board in my opinion ;)
Since two weeks we are now one team - which seems to work better despite the number - and skipped task moving at standup.
Also because of Jira we are now doing a story based standup - which seems to work better.
(Unfortunately had to adapt to the tool. I have now story swimlanes and we go top to bottom - so reduced scrolling.)

Now to answer some of Rons questions/statements:

> Two developer may start the same task because it is still open on the board

Has happend - not in my team but a college told me. Their solution was that if you took a task from the board you asked in the room if this is OK.
(Actually I like this approach as it allows the team to give the implementer additional infos - but I would still update the tasks immediately :)

> Kanban doesn't limit work unless people follow the limits, which the board does not force.

But the board helps by having it visual - thats why we have the boards - right? (And our Jira board can force ;)
And as SM you could then enforce it - if you would know the status...

> - No overview about Sprint status changes (e.g. in critical and urgent situations we had)

I am generating a Task Burndown before the standup that is shortly discussed - this is not possible without prior update
The mentioned critical situation was during a week of defect fixing prior a release - each developer had many small defects to fix and on the first day tasks were piling
up in the progress column - we had no clue of the actual status and the POs got worried about the release.
We switched the next day to changing status immediately which gave us a better picture and more confidence.
Of course I could have asked everyone from time to time - but I think that would have been just disturbing to them.

Which brings me to your question which made me think - who needs the realtime status?
The answer would be: Mostly I as SM. I still think its beneficial for the team members as well but for me it
is important to be able to see what is going on (multitasking, burndown, answering status questions,...)

Br
ML

[Dan Rawsthorne]

I'll even get more basic than Ron. Why do you have tasks? Why do you update them? How does this help you produce quality results?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of Exploring Scrum: the Fundamentals

[bru...@gmail.com]

Hi,

I want visibility, transparency, and quick feedback.
This helps me to produce quality results.

Thats why I have a board with some work item on it - if its a task or story does not matter.
And thats why I want to see whats going on as soon as possible to have short feedback cycles.

Br,
ML

[Ron Jeffries]

On May 24, 2013, at 7:50 PM, bru...@gmail.com wrote:

I want visibility, transparency, and quick feedback.
This helps me to produce quality results.

Are you a programmer on the project? If not … ?

Thats why I have a board with some work item on it - if its a task or story does not matter.
And thats why I want to see whats going on as soon as possible to have short feedback cycles.

What do you actually DO with this information? What is being slowed down or prevented because you only get it every 24 hours? What would you likely do if you got it sooner?

Ron Jeffries

www.XProgramming.com

Sometimes I give myself admirable advice, but I am incapable of taking it.

-- Mary Wortley Montagu

[Dan Rawsthorne]

So, how do tasks do that? You prefer documentation over actual results?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of Exploring Scrum: the Fundamentals

[bru...@gmail.com]

Hi,
I am SM - not a programmer (but was before)

As said above - I dont care about Tasks - I care about visibility of Work Items. The team has tasks - so fine with me.

> What do you actually DO with this information? What is being slowed down or prevented because you only get it every 24 hours? What would you likely do if you got it sooner?

I see problems earlier - not only once a day - which helps me for my SM duty as I get a better feeling what is going on.
Think of a movie where always jump ahead 10 minutes and watch then for 30sec.  Does this help you understanding the plot?

Or do you suggest We dont need a board?
If the board dont has the actual status - so why do we need it at all?
If it is not beneficial to update immediately - why do we do it daily?
If we dont need Work items - as Dan suggested - why do we need backlogs?

Br
ML

[Ron Jeffries]

Hi Bruce,

On May 25, 2013, at 3:54 AM, bru...@gmail.com wrote:

I am SM - not a programmer (but was before)

As said above - I dont care about Tasks - I care about visibility of Work Items. The team has tasks - so fine with me.

That's interesting. Leads to these questions, at least:

What is it that your Product Owner values most? Do they just value "tasks"? Are they getting the visibility into what is going on that they really need? Do tasks help them understand how best to do their job?

What does deeper visibility into the work flow provide to the project? What are things on the project that are not going as well as they might? Are these things being brought up in the retrospectives? What happens then?

> What do you actually DO with this information? What is being slowed down or prevented because you only get it every 24 hours? What would you likely do if you got it sooner?

I see problems earlier - not only once a day - which helps me for my SM duty as I get a better feeling what is going on.
Think of a movie where always jump ahead 10 minutes and watch then for 30sec.  Does this help you understanding the plot?

Are there Sprint Planning meetings, Sprint Demo/Reviews, Sprint Retrospectives? Is there regular backlog grooming involving the team? What information are you getting from those? What information are you missing? 

Or do you suggest We dont need a board? 
If the board dont has the actual status - so why do we need it at all?
If it is not beneficial to update immediately - why do we do it daily? 
If we dont need Work items - as Dan suggested - why do we need backlogs?

I understand that you //want// this information.

I am asking you what you will //actually// //do// with this information. What will //really// be slowed down or prevented.

What have you actually seen or heard happen in this very team that would be have gone better had information been available sooner? Can you think of a specific incident?

Was the above issue that actually happened brought up in the retrospective? What happened then?

[Steve Berczuk]

On Sat, May 25, 2013 at 6:00 AM, Ron Jeffries <ronje...@acm.org> wrote:
>
> I understand that you //want// this information.
> I am asking you what you will //actually// //do// with this information.
> What will //really// be slowed down or prevented.
>
> What have you actually seen or heard happen in this very team that would be
> have gone better had information been available sooner? Can you think of a
> specific incident?
>
> Was the above issue that actually happened brought up in the retrospective?
> What happened then?

I apologize if I missed this in the thread, but did you ask the team
if they would consider updating more often?
I see a problem if the SM wants the team to do something to
micromanage the team, but I also see a problem if the team resists
considering a change because "that's not the way it's done."

By default, it's probably best if the team does what helps them
develop software best, but it's not a bad thing to do something that
might the other stakeholders help them,

--
Steve Berczuk | steve....@gmail.com | http://www.berczuk.com
Twitter: @sberczuk
ADN: @spb
SCM Patterns: www.scmpatterns.com

[Pierre Neis]

Task status are updated when something happen and at least at Daily Scrum.

In my teams, only $crum Master update task status in the system, and only when done.

Kind regards, cordialement, mit freundliche Grüsse,

Pierre E. Neis 
Scrum/Lean Coach - Senior Management Consultant



Agir Anticiper Durablement sarl
19 place Bleech |L-7610 Larochette | Luxembourg
M: +352 661 727 867

email:  pierr...@we-and-co.com
web:    http://wecompany.wordpress.com/
Meet with me: http://meetwith.me/pierreneis
 

Contact me: pierre.neis

Get a signature like this. CLICK HERE.  

[bru...@gmail.com]

Hi,

Maybe I have overlooked it - but for me it seems that nobody so far (except Yves and dan)
has told me concrete issues with my approach nor reasons for doing it otherwise.

I just wanted to know why others are doing it different? What are the reasons?
Please tell me the drawbacks of my approach.

I appreciate it that you all had nice suggestions and interesting questions regarding my team - I got new input here too.
But could you also give me some concrete pros and cons regarding my question?

Why would YOU not do it?
What HARM does it do?

Again: THIS IS NO ISSUE WITH MY TEAM!!! (We have other ones - but this is running smoothly)
- Team members are fine with updating immediately - and usually do it 
- POs like it more than before
- I have a better overview of what is going on

@Updating status - my points again:
I see it like Pierre:
Task status should be updated when something happen and at least at the Daily Scrum.

For me it feels strange to wait - it feels like waste.
Almost as if I would ask the developers to check in code only during a daily 15 minute timebox.
Sounds strange - doesn’t it? Thats how it feels to me!

Isn't it an agile principle to take a small work piece, finish it, and only then take on the next?
How is this supposed to work if you cannot change the status of the task - which for me is part of the work.
Therefore, work is not finished until this is done.
So waiting until the daily scrum inevitable leads to multitasking.
Unfinished work also occupies part of our energy, attention, and time.
How would a production line look if you had to wait a day before you move your items to the next stage?

@Pierre:
I don’t understand is why only the SM updates the tasks. Why not the developer?
Any reasons for this?

@Ron
I don’t think it matters for my question but you gave me other things to think about.
So here are my answers:

- Our POs care about finished stories and story status. Whatever helps them to see this is fine.
- Yes we do the meetings and everything (still not perfect but OK and improving).
- As mentioned above:
  - I use it to: Answer PO status requests, detect multitasking
  - Not having it slows down: Standup, overall reaction time, PO feedback
  - Concrete Issue encountered:
    Defect fix phase with many small defects before important release - testing session in parallel.
    -> first day: no overview who had which workload and what was the status - had to interrupt developers to find out
        Testers were not sure if Bugs should be already fixed or really in progress.
    -> second day - with update: I could give better Info for POs without interrupting developers.
       Testing members could easier check if a newly found defect should be fixed or is in progress.
       POs less nervous - could better decide which defects might be possible to fix.
    -> Did not came up during retro as the issue was solved immediately.
       Since then we stick to instant updates and don't wait for the daily

Br
ML

[John Miller]

Self-organization is supported when teams  know what tasks are Ready, which tasks are WIP, and which tasks are Done so that any member can pull a new task or help with  another at anytime (instant availability). The board serves the team 24/7, not just during the 15 minute Standup.  I would suggest real time updates to serve a self-org team. I suggest using the Standup, as far as the board goes, to ensure the tasks are up to date, but, it is not the only time to update them.

I have used this approach and it works. I would not say it is the only approach that works, do what works for your situation. Experiment, inspect, adapt.

Thanks,

John Miller

http://theagileschool.blogspot.com/

“Set patterns, incapable of adaptability, of pliability, only offer a better cage. Truth is outside of all patterns.” 
― Bruce Lee, Tao of Jeet Kune Do

[Daniel James Gullo]

Bruce-

"Common Practices" aren't necessary good practices or bad practices.  In my experience, I have seen teams move tasks whenever they were complete.  I have also seen teams wait until the Daily Scrum.  I have also seen teams not use Tasks at all.  They identified a workflow with various states and moved User Stories across the workflow.  I have seen teams not move things for days.

I don't tell organizations what to do.  I present the options with the pros and cons and ask them what they would like to try first and why.  At the end of their first Sprint, they will reflect during the Retrospective on whether that approach worked or not and what they want to try next that would be different, if anything.

What problem(s) do you see with the way your new organization is currently functioning?  Have you been there long enough to gauge whether it really is a problem or not?  What would you suggest that would add value and why?

Ganbarimasu-

Daniel Gullo

CSC, CST, PMP

Trinacria Consulting

daniel...@trinacria-consulting.com
302-276-4454

I am speaking at:

2013 Regional Scrum Gathering China  ( Beijing: June 29-30;  Shanghai: July 3-5;  Suzhou: July 5-6 )

2013 Scrum Gathering Paris ( September 23-25 ) - #sgcdg

On May 23, 2013, at 18:19 , bru...@gmail.com wrote:

Hi,

I have a question regarding when to update tasks in Scrum - or what is the "best practice" most teams follow.

Recently I started as Scrum Master in a bigger company (>30 Scrum teams).
There I encounter something odd (for me): Tasks were only moved at the daily standup.
And I was told that this is pretty common in most Scrum teams

I have been doing agile for a while now (XP + Kanban) but I am new to Scrum.
So for me its strange as up until now I used to see the taskboard as realtime status info.
(And Kanban wouldn't even work that way)

So I wanted to ask if it is really a common practice in Scrum to wait with updates for the standup?
And if yes - what is the reason?

Cheers,
ML

[John Miller]

@Pierre:
I don’t understand is why only the SM updates the tasks. Why not the developer?
Any reasons for this?

The person who pulls the tasks moves the tasks through. A subtle influence like the SM updating tasks can lead to a perception of the SM in control and that we report to the SM.  

@Ron
I don’t think it matters for my question but you gave me other things to think about.
So here are my answers:

- Our POs care about finished stories and story status. Whatever helps them to see this is fine.

IMO, the PO does not need to worry about the status of a story in progress. The team has got it. The PO should be concerned about how to serve the team to give them the right information and feedback as the team needs it. Very different from Story status. The team does not need to report to the PO.

  - I use it to: Answer PO status requests, detect multitasking

The PO should not need to be updated. The board communicates, the team members communicate. The SM should not be the "reporter". The whole team (PO, SM, Dev Team) should be collaborating.

It sounds that there is an imbalance and misunderstanding of the PO/SM/Team, I might want to look deeper into relationship and clarifying the responsibilities .

• PO: What
• Team: How
• SM: Serves/Coach
• All Collaborate

Br
ML

[George Dinwiddie]

Pierre,

On 5/25/13 10:32 AM, Pierre Neis wrote:
> Task status are updated when something happen and at least at Daily Scrum.
> In my teams, only $crum Master update task status in the system, and
> only when done.

Ugh! There are many ways of working, but this is one of my least
favorite. It reminds me of a PMP updating a Gantt chart as the minions
complete their assigned tasks from the WBS.

I prefer to leave a lot of this up to the team (the Whole Team) to
determine what seems helpful for them. If asked for my opinion, I would
prefer:

1. To track slices of functionality, not tasks.
2. To slice functionality small enough that you can see progress at
least every day or two.
3. That developers (both programmers & testers) divide the work into
tasks as formally or informally as they wish.
4. That developers show working functionality to the PO as soon as
it's working.
5. That the Whole Team (at least, those involved in this story) move
the card to Done when the PO agrees it's working.
6. (Optional) That the people ring the gong when they move the card to
Done. Others may wish to look up from their work and cheer.

I've seen this work really well, and I've seen a lot of more elaborate
schemes work not as well.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Steve Berczuk]

On Sat, May 25, 2013 at 12:53 PM, <bru...@gmail.com> wrote:
> Maybe I have overlooked it - but for me it seems that nobody so far (except
> Yves and dan)
> has told me concrete issues with my approach nor reasons for doing it
> otherwise.
>
> I just wanted to know why others are doing it different? What are the
> reasons?
> Please tell me the drawbacks of my approach.

My take on this question (and perhaps the same view of those who have
asked more questions than provide answers -- though guessing what
other people thing is rarely productive) is that it doesn't really
matter what other teams do. What works for your team is what matters,
and the right way to improve how you work is to talk together.

I think is it safe to say that many teams do things many different
ways, and as long as there is an accurate status on the board at
Standup, and as long as the team members are not stepping on each
other, it does not matter....

So "why do you want to know what other teams do and what would you do
with the information?"

Steve

[John Miller]

+1 George

(I just would say the team as programmers and testers are too limiting, a team may have more roles than this and a person is so much more than a role like programmer/tester)

Thanks,

[George Dinwiddie]

John,

On 5/25/13 1:39 PM, John Miller wrote:
> +1 George
> (I just would say the team as programmers and testers are too limiting,
> a team may have more roles than this and a person is so much more than a
> role like programmer/tester)

Yes, I made that statement because many people assume that "developer"
only includes programmers.

[Markus Gärtner]

"Again: THIS IS NO ISSUE WITH MY TEAM!!! (We have other ones - but this is running smoothly)"

Bruce, I am confused now. If your team does not have an issue, they will not change anything. So, what is it we are discussing here? A potential problem somewhere in unicorn land?

Best Markus

--

Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

[Ron Jeffries]

Hi Bruce,

On May 25, 2013, at 12:53 PM, bru...@gmail.com wrote:

Maybe I have overlooked it - but for me it seems that nobody so far (except Yves and dan)
has told me concrete issues with my approach nor reasons for doing it otherwise.

In my case, that's primarily because I want to invite you to think about the pros and cons, not just ask questions about "your approach".

I just wanted to know why others are doing it different? What are the reasons?
Please tell me the drawbacks of my approach.

The primary drawback of your approach might be that it is "your approach". The Dev Team in Scrum is self-organizing, not organized by the ScrumMaster. The ScrumMaster's job is to resolve impediments -- impediments that are identified by the team. 

I appreciate it that you all had nice suggestions and interesting questions regarding my team - I got new input here too.
But could you also give me some concrete pros and cons regarding my question?

Why would YOU not do it?
What HARM does it do?

If the team wants to update immediately, it will surely do no harm and might be valuable. If YOU want them to do it, and somehow cause them to do it, it will create a relationship between you and the team which may not be desirable, somewhere between their waiting for you to tell them what to do and your thinking you actually have a right to tell them what to do.

Again: THIS IS NO ISSUE WITH MY TEAM!!! (We have other ones - but this is running smoothly)
- Team members are fine with updating immediately - and usually do it  
- POs like it more than before
- I have a better overview of what is going on

I do not understand. If your team is updating immediately, why are you asking the questions? Is this just a request for information and background? I had been thinking you were looking to make a change. In that light, I'd hope to see a problem and a proposed improvement before making a change.

Anyway, if information and background is what you need, the answers people have been giving are rich with that. People are talking about what really happens in the process, more than what cards on a board say.

@Updating status - my points again:
I see it like Pierre:
Task status should be updated when something happen and at least at the Daily Scrum.

For me it feels strange to wait - it feels like waste.
Almost as if I would ask the developers to check in code only during a daily 15 minute timebox.
Sounds strange - doesn’t it? Thats how it feels to me!

You probably recall that the Daily Standup is the finest-grain event for examining where we are that Scrum recommends. If the Scrum creators thought a finer grain was desirable, they'd have recommended it. 

There is a need for people to know where things are -- but it is an odd one. Recall that changes to the backlog (from the PO) are not allowed during the Sprint. The team is responsible for delivering the best possible result by the END of the Sprint.

The team has to know, well enough, what is going on. The Product Owner wants to know … and if she does, it makes me wonder why. Does the team have a record of not doing what they say? Does the PO have some other legitimate concern? Or is there a deplorable tendency to pick the team up by the roots to see how they are growing. 

A desire for frequent views of an activity that actually produces results every few days makes me want to know "what's wrong", not just produce more frequent views.

Isn't it an agile principle to take a small work piece, finish it, and only then take on the next?
How is this supposed to work if you cannot change the status of the task - which for me is part of the work.

You're not doing the work. The team is. If the team knows where they stand, that's good enough. If they do not know where they stand, and need to, something visible will go wrong, and as their "coach" you have the right and responsibility to bring it up and have them deal with it in the retrospective. If nothing is going wrong, it's hard to justify tampering with what they're doing.

Therefore, work is not finished until this is done.

I think this statement is simply wrong. The work is done. The status board is not part of the work, it's part of some administrative overhead which, apparently, you value more than the team does. Day to day, inside the Sprint, I'm more concerned about what the team needs. If they need more information, again, we should be able to identify that need via something going wrong.

So waiting until the daily scrum inevitable leads to multitasking.

That's not clear. People could be finishing one thing and then starting another. Moving the card isn't part of the work.

If there is multitasking, it may or may not be bad. I'd want to look at it to find out what is going on. Sometimes working heads down on one thing isn't the best thing to do. Or perhaps there are visible impediments to working on the first thing which should be identified and fixed.

Unfinished work also occupies part of our energy, attention, and time.
How would a production line look if you had to wait a day before you move your items to the next stage?

This is not a production line. Yes, it's good to limit WIP. But there is no evidence that you have given us, despite all our questions, showing that WIP limits are not being honored. If they are not, there should be some visible negative impact. If there is, identify it and get the team to fix it. They might fix it by updating the task board more often but frankly I can think of absolutely no real impediment that will be fixed by a status update. Well, not true, I know of one time when a status update fixed an impediment.

@Ron
I don’t think it matters for my question but you gave me other things to think about.
So here are my answers:

- Our POs care about finished stories and story status. Whatever helps them to see this is fine. 

Good this goes back to Dan's question about why you're not posting story status and not using tasks. 

Your job includes explaining to the PO that they are not there to get every day status: they are there to provide a backlog at the beginning of the Sprint which can be implemented by the end. Their desire to know what's happening moment to moment is a process smell that I'd like to look into. I would not likely fix it by providing moment to moment information.

- Yes we do the meetings and everything (still not perfect but OK and improving).
- As mentioned above:
  - I use it to: Answer PO status requests, detect multitasking
  - Not having it slows down: Standup, overall reaction time, PO feedback

If moving the card is taking a lot of time, people should stand nearer to the board. I really suspect this is not the biggest time waster to deal with. Perhaps you should move closer to the restrooms, or remove the magazines. :)

Reaction time? What reaction time? Are you suggesting that when someone is done working on something, he doesn't know it? Or are there people waiting for things to be done, who do not know until standup that they can proceed? If those things are happening, they are concrete impediments which need to be dealt with by the team. Updating the board might be one way ...

  - Concrete Issue encountered:
    Defect fix phase with many small defects before important release - testing session in parallel.
    -> first day: no overview who had which workload and what was the status - had to interrupt developers to find out
        Testers were not sure if Bugs should be already fixed or really in progress.

Good. Resolve this. What happened when this came up in the retrospective? What solution did the team offer?

    -> second day - with update: I could give better Info for POs without interrupting developers. 

There is something wrong with your team if the PO needs updates every day. Furthermore, if in fact they need updates every day, the team should be providing them, using some means that makes sense to them.

Are you running a continuous build? If that's the case, the status of which bugs are fixed should show up there, should it not? And if you aren't … I'd guess that's causing more problems than moving the cards around would fix.

       Testing members could easier check if a newly found defect should be fixed or is in progress.

This seems like a need for a conversation, not for one person to move a card and another person to discover later that it is moved. Also sounds like you are testing after the fact. There are better ways to be sure things work, and again, these are more likely fruitful areas to work on than card moving.

       POs less nervous - could better decide which defects might be possible to fix.

Again a process smell. It sounds like your team isn't doing a very good job keeping defects out. If they are coding more or less without acceptance tests and then later getting feedback from separate testers, that is the primary cause of defects building up. 

    -> Did not came up during retro as the issue was solved immediately.
       Since then we stick to instant updates and don't wait for the daily

So … you have what you want already. Cool ...

Ron Jeffries

www.XProgramming.com

Perfectionism is the voice of the oppressor -- Anne Lamott

[Yves Hanoulle]

Scrambled by my Yphone

Op 25-mei-2013 om 19:33 heeft George Dinwiddie
<li...@idiacomputing.com> het volgende geschreven:

> Pierre,
>
> On 5/25/13 10:32 AM, Pierre Neis wrote:
>> Task status are updated when something happen and at least at Daily Scrum.
>> In my teams, only $crum Master update task status in the system, and
>> only when done.
>

Pierre, Will you tell us, why your (?) teams, work like this?

> Ugh! There are many ways of working, but this is one of my least favorite. It reminds me of a PMP updating a Gantt chart as the minions complete their assigned tasks from the WBS.
>
> I prefer to leave a lot of this up to the team (the Whole Team) to determine what seems helpful for them. If asked for my opinion, I would prefer:
>
> 1. To track slices of functionality, not tasks.
> 2. To slice functionality small enough that you can see progress at least every day or two.
> 3. That developers (both programmers & testers) divide the work into tasks as formally or informally as they wish.
> 4. That developers show working functionality to the PO as soon as it's working.
> 5. That the Whole Team (at least, those involved in this story) move the card to Done when the PO agrees it's working.
> 6. (Optional) That the people ring the gong when they move the card to Done. Others may wish to look up from their work and cheer.
>
> I've seen this work really well, and I've seen a lot of more elaborate schemes work not as well.
>
> - George
>
> --
> ----------------------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------------------
>

[Pierre Neis]

Hi guys,

So here the why I use this:

1. the PMO wants to track daily work, developer's commitment, complete task on Jira (or what ever).

    Result: - individualistic behavior and no commitment between team members

               - part time commitment and resource allocation management by Scrum Master

               - introduce high risk of project failure and scrum butting

               - waste + overtime + bad quality + lost of focus

    this for 70% of the projects 

    Action: stop logging the chronograph, 8H work on Flex Time, Scrum Master produce weekly Timesheets (idea came from a post of Henrik Kniberg)

2. in one program in Germany, we had a lot of debate between Management and Scrum Team. Reason was double reporting and bad task tracking. 

  Actions: - PO accountable for Done increments, ROI and Time to Market

               - SM accountable for task reports + capacity management

               - management commits only on work done: has been made possible with co-located PO in Team's room

3. Scrum Orthodoxy allowed me to:

   - reinforce the role of the PO (by the book --> can say no to the client & management)

   - let the development team free of time tracking

4. Lessons learned:

   - this is should applicable with parsimony according to organization's culture

   - Developers were free to follow or not this approach but SM was still accountable

   - interesting outcome was also the reinforcement of the SM in traditional PM structure (Prince 2, PMBok, Hermes)

As conclusion, this is right to mention that a "PMP"like risk exist!

Core is : Dev Team work in a Pull system, if any action is blocking the focus on deliver "Done" tasks then it's SM's job.

No?

Can sound a bit straight but I'm really lovely ;b))))

 

            

Kind regards, cordialement, mit freundliche Grüsse,

Pierre E. Neis 
Scrum/Lean Coach - Senior Management Consultant



Agir Anticiper Durablement sarl
19 place Bleech |L-7610 Larochette | Luxembourg
M: +352 661 727 867

email:  pierr...@we-and-co.com
web:    http://wecompany.wordpress.com/
Meet with me: http://meetwith.me/pierreneis
 

Contact me: pierre.neis

Get a signature like this. CLICK HERE.  

[bru...@gmail.com]

Hi,

Thanks, now I got some answers.

Why I ask without having an issue?
I am curious amd want learn from others to have new  options.

I am aware that there a many ways to do thing - but each one has reasons and implications
And I dont want to try all - so I wanted to asked here:
Why do you do it your way?

And afterward I maybe will try some and see.
So its no unicorn land problem solving.
I was intended as real world experience collecting.

Just for clarification:
Our testers are also programmers
In the mentioned testsession we split and a few were fixing defects while the others were testing.


@John
Thats my point of view - I want to encourage self-organizing and transparency
But for POs and roles - IMHO it is also:
 SM - protect team
 PO - responsible to customer - and because of his promises to the customer he had to worry about story status (estimates came from team)
 So in the described release situation it was the POs job to get feedback from the team for some decisions and my job to protect them so they could work. 

@Daniel
That is exactly what my question was about - to find out options and pros and cons as well as experiences with different scenarios.
Its not about organizational problems or common practices to follow. Its about options, pros and cons.

@George
So far I did it mostly like you suggested (and it worked very well for the last 5 years)
- We tracked small stories (1-3 days) and had no tasks
- No dedicated tester - but another developer (which had not worked on the story) tested the stories
- After testing and fixing it was immediately acceptance tested from involved developers with the PO
- Status was set as soon as it changed by developer - only move to done by PO (kind of signed :)
- No gong on acceptance (Haven't thought of it - Thanks - another point to take with me :)

@Ron
Mainly it was a request for information and background
I have thought about pros and cons - but I wanted other peoples opinions to gain new insights - and I got some here - also from you - Thanks.
And Yes - its MY approach - I would do it like described above
But in my new company they do it different - not better nor worse - just different.
It works for them - but should that mean there is no need for me to act if I have the feeling something smells?
I think my job as SM is to help the team to improve.
I don't dictate my approach (although sometimes I really would like to ;) but instead I propose changes and experiments.
And I ask the team to REALLY try things for some time - and then decide.
So its a team decision - and not me dictating.
My final goal as SM is to enable the team to work smoothly without me.

As you mention the daily Scrum as finest grain to see status: The Scrum guide speaks of the Sprint backlog as real-time picture - not as daily picture
So the Scrum creators have thought of a finer grain and have mentioned it:
"Monitoring Sprint Progress: At any point in time in a Sprint, the total work remaining in the Sprint Backlog items can be summed.
The Development Team tracks this total work remaining AT LEAST for every Daily Scrum."

I also have to disagree with your opinion that the status update is not part of the work.
Yes it is administrative overhead but it is tightly coupled with a piece of work.
So for me it is part of the work as long as it is mandatory for the team to do it (which of course is up to them).

For multitasking: I agree that its sometimes useful to have 2 items in progress - but 5? Shouldn't I ask then?
And how I am supposed to see this if I am not having a realtime picture? (maybe 4 are finished and are just waiting to be moved?)
And if I don't see it - how can I bring it up in the retro?
(Which I did by the way - we agreed that its not good. I took the lead to remind the others this sprint - therefore, I need an instrument to see it...)

And for the smells and team problems - you are right. We have many :)
But this is what I mentioned above - some of them seem to be normal for the team - but for me as outsider they are strange (I started in April - so I'm still fresh :)
And as SM I see it as my job to tell them and propose options.

Some Examples and measures so far:
- Distributed team
 - Standup task updates via Jira took long -> skipped task update
 - Standup no overview on Jira board -> created new board with story swimlanes
 - Standup no visible story status -> created google docs story timeline
 - offshore team part not meeting quality standards -> try to educate and make additional separate short retro - as they have different problems in their environment.

- Team is over committing - Velocity is a strongly fluctuating - (stories often need fixes and are accepted in the next sprint)
  -> try story scheduling and remind on past velocity
- Team decided to do Retro "on demand" (= skipping it) -> asked the team for reasons and for trust to do it again for some sprints and then reflect
- No stories prepared on time -> instantiated now regular sprintly grooming meeting
- Testing icecone - no TDD -> started monthly coding dojos
- Many Juniors - few seniors -> try to introduce pairing
- Other depended projects with different deadlines
...

So definitely not boring... :)

Br
ML

[John Miller]

Bruce,

"PO - responsible to customer - and because of his promises to the customer he had to worry about story status (estimates came from team)
 So in the described release situation it was the POs job to get feedback from the team for some decisions and my job to protect them so they could work. "

I see a need for conversations between the PO & Dev Team. Needing to see status of tasks on the board is smells of a lack of trust & collaboration. Does the PO attend standups? How does the worry of the PO help the story get to done when she has no control over the tasks ? I would think this extra level of hawking over the team by the PO would impede their progress. 

  The PO does not commit work delivered to the customer in the Sprint or the customer.  The smell points to possibly many or all of the  below Agile principles being deficient. I would look here, ask questions, and get to the root. 

Business people and developers must work together daily throughout the project. (Sounds like the PO and developers are not doing this)

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. (Not task card updates and status reports)

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.(sounds like lack of trust and focus is on managing the team versus providing a better environment)

Working software is the primary measure of progress.(not tasks. Tasks may change in a sprint, why does the PO need to monitor them. PO should worry about did I provide a clear ) 

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

[Tobias Mayer]

As a ScrumMaster you should have zero interest in how many tasks are moved or how often. You are not some kind of process monitor, and you are agnostic to business outcomes—that's the POs job. 

Your interest should be in whether or not the team find their process effective, and if not to guide them towards a more effective one. So rather than asking here about how often tasks should be moved, ask the team. Better, ask them if they are getting the information they need in a timely fashion, and if not how might they improve that.

You may also want to ask the PO if she is getting the information she needs, when she needs it. If you have a PO tracking tasks also, suggest she attends a Scrum training to learn the PO role better :)

A scrum master is not a project manager. A scrum master is an agent of change. Look wider.

Tobias

[Dan Rawsthorne]

Well said, Tobias. Good to hear from you...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of Exploring Scrum: the Fundamentals

On 9/12/2013 1:05 PM, Tobias Mayer wrote:

As a ScrumMaster you should have zero interest in how many tasks are moved or how often. You are not some kind of process monitor, and you are agnostic to business outcomes�that's the POs job.�

Your interest should be in whether or not the team find their process effective, and if not to guide them towards a more effective one. So rather than asking here about how often tasks should be moved, ask the team. Better, ask them if they are getting the information they need in a timely fashion, and if not how might they improve that.

You may also want to ask the PO if she is getting the information she needs, when she needs it. If you have a PO tracking tasks also, suggest she attends a Scrum training to learn the PO role better :)

A scrum master is not a project manager. A scrum master is an agent of change. Look wider.

Tobias

On Thursday, May 23, 2013 3:19:25 PM UTC-7, bru...@gmail.com wrote:

Hi,

I have a question regarding when to update tasks in Scrum - or what is the "best practice" most teams follow.

Recently I started as Scrum Master in a bigger company (>30 Scrum teams).
There I encounter something odd (for me): Tasks were only moved at the daily standup.
And I was told that this is pretty common in most Scrum teams

I have been doing agile for a while now (XP + Kanban) but I am new to Scrum.
So for me its strange as up until now I used to see the taskboard as realtime status info.
(And Kanban wouldn't even work that way)

So I wanted to ask if it is really a common practice in Scrum to wait with updates for the standup?
And if yes - what is the reason?

Cheers,
ML

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.

Visit this group at http://groups.google.com/group/scrumalliance.

[mj4s...@gmail.com]

It's good to hear from you. 

And I agree, of course.  

--mj

(Michael)

Sent from a phone that often corrects words I tapped to words I may not have meant. 

[John Miller]

I agree, except the comment of "agnostic to business outcomes".

I would think that the entire team, including the SM, would care about the success of the business outcome.

Most want our work to have purpose and meaning,including the SM.

Thanks,

John Miller

http://theagileschool.blogspot.com/

[Tobias Mayer]

I can care about business outcomes, yet not be bound by them. My purpose and meaning comes from seeing people engaged in their work, building healthy community and pushing their edge. As soon as I have a vested interest in the business outcome I can no longer be the best scrum master I can be. One person in the team needs to see the world differently. That person is the scrum master.

Healthy teams create compelling products. The scrum master has to care about the team. The team cares about the product. There's a level of indirection there that I like :)

Tobias

[Ron Jeffries]

Tobias,

On Sep 13, 2013, at 7:50 PM, Tobias Mayer <tobias...@gmail.com> wrote:

I can care about business outcomes, yet not be bound by them. My purpose and meaning comes from seeing people engaged in their work, building healthy community and pushing their edge. As soon as I have a vested interest in the business outcome I can no longer be the best scrum master I can be. One person in the team needs to see the world differently. That person is the scrum master.

I'm not grasping this. Can you think of an example (made up or not) where vested interest in the business outcome might conflict with caring about the team?

Ron Jeffries

www.XProgramming.com

[Daniel James Gullo]

Ditto.  Just as quality is everyone's responsibility, so is customer delight.  If the business outcomes aren't aligned with delivering customer delight, then they are the wrong business outcomes and that's an impediment that needs to be addressed.

"How can I make a difference so that I may bring peace to this world that I love and cherish so much?" - Gandhi

[Daniel James Gullo]

*expected business outcomes

"How can I make a difference so that I may bring peace to this world that I love and cherish so much?" - Gandhi

[mj4s...@gmail.com]

Yes. Actually the "David Story" is a good illustration of this. I may elaborate when I get to a keyboard. 

--mj

(Michael)

Sent from a phone that often corrects words I tapped to words I may not have meant.