Is this the right way to update status in Daily Standup Meetings?

[Satyaprakash Joshii]

In any daily standup meetings one needs to tell 3 things :
1) What I worked on yesterday ?
2) What I will work on today?
3) Any impediments?

Is below a right example on how one should update the status for an example user story  to create REST API to read data and then upload it on S3 using Lambda function?

Yesterday, I worked on task XYZ and implemented the code for API which reads the request.
Today, I will work on the task ABC and implement the lambda function which sends this data to the S3 bucket ?
There is an impediment that I do not have access to create lambda function.Estimate for this is 16 hours.

Is this a right way ?

[Stephan van Hulst]

You're thinking too hard.

1) What I worked on yesterday ?

The best thing to do here is tell people what you did yesterday.

2) What I will work on today?

For this one, tell people what you plan on working on.

3) Any impediments?

I think the best strategy here is to tell people what you're stuck on.

[Satyaprakash Joshii]

Yes but there is an ineffective way of stating this which would leave the scrum master also have a hard time understanding and there is a good effective way of stating which is how the scrum master would find useful and quick to understand.

The best thing to do here is tell people what you did yesterday

There is a way developer would speak from his angle and there is a way the scrum master expects.The former may be confusing for the scrum master to understand while the latter would lead to more effective standup meetings.

So is the example I gave above the good way(the way scrum master expects for the daily standups to be effective) or is there a better way then the one I have written above?

[Stephan van Hulst]

Standup meetings are not for the scrum master. They are for all colleagues in the room. The scrum master only moderates, and it's their job to tell you when you're being too specific or not specific rough.

Adapt to your audience. If most colleagues are technical like you, you can go into the technical details a little bit more, but keep it short.

The most important part of the standup is to make it clear if some things are taking longer than expected and if you need help. Try to explain what is wrong in general terms, so that colleagues that you expect can help you will get enough background so that they might offer their help.

In your example of an impediment, you said you didn't have access to create lambda functions and that you expect 16 hours delay. What do you base this delay on? And why haven't you told what you are doing to handle the impediment, or haven't asked for help?

[Satyaprakash Joshii]

Stephan van Hulst wrote:
In your example of an impediment, you said you didn't have access to create lambda functions and that you expect 16 hours delay.

16 hours overall time to do the task (not delay).

[Satyaprakash Joshii]

Stephan van Hulst wrote:And why haven't you told what you are doing to handle the impediment, or haven't asked for help?

That's right.

[Satyaprakash Joshii]

Stephan van Hulst wrote:The scrum master only moderates, and it's their job to tell you when you're being too specific or not specific rough.

Right. But being good professionals we should not wait for them tell , we ourself should also know that what's the good way.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:

Stephan van Hulst wrote:The scrum master only moderates, and it's their job to tell you when you're being too specific or not specific rough.

Right. But being good professionals we should not wait for them tell , we ourself should also know that what's the good way.

SM is a coaching role. I'm a SM as 25% of my job (and a developer the rest.) I invest in coaching new people on how to communicate better. It definitely pays off. Expecting someone to know this just because they are senior isn't a recipe for success.

That said, after getting some coaching, people should start to communicate in a way that fits the meeting better.

I think your yesterday/today examples are fine. For the impediment, I'd prefer "There is an impediment that I do not have access to create lambda function.Does anyone have access or know how to request it?"

[Satyaprakash Joshii]

Jeanne Boyarsky wrote:[ For the impediment, I'd prefer "There is an impediment that I do not have access to create lambda function.Does anyone have access or know how to request it?"

That's right.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote:communicate in a way that fits the meeting better.

Case 1) Yesterday I worked on lambda function which sends the data to S3. I checked that  by sending request using Postman.The data was there on S3.

Case 2) Yesterday, I worked on task ABC. I implemented code for lambda function which sends data to S3.
It is completed.


In Case 1, the developer just spoke from his angle.
In Case 2, the developer spoke from the angle how it is required. Task ID ? Status : Completed/In progress? Description?

Is Case 2, a better way and it would be easier for scrum master to quickly undertand the actual status ?

[Jeanne Boyarsky]

It's not up to the developers to make things understandable for the SM. As someone mentioned earlier, the standup is for the team. It is useful for the team to know which task/story you are working on.

Years ago, my team switched to a story based format for standups. For each story/task (in priority order), the story owner covers what was done yesterday/what is being done today and any impediments. This has the benefit of making sure we are focused on the highest priority items. It also requires more trust and communication because the story owner is speaking for everyone working on the story not just him/herself. Which means there could be a day where someone says nothing/little at standup. And that's ok! We know everyone is doing work.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote: standup is for the team

What does this mean ?

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:

Jeanne Boyarsky wrote: standup is for the team

What does this mean ?

The official Scrum guide says:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

Note what this quote says about the audience. The meeting is for the developers. The SM is allowed to attend. The SM is allowed to coach on how to run the meeting better. But the meeting is not for the SM. It is for the team.

[Dave Tolls]

What Jeanne says.
You are not reporting to the scrum master (a common misconception, it has to be said).
You are keeping the team informed about where you're at with your work.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote:
Note what this quote says about the audience. The meeting is for the developers.

Yes the below says it is for the Developers

Daily Scrum is a 15-minute event for the Developers

But it also says the purpose as below.Isnt this something the SM will do and not the developers ?

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

[Satyaprakash Joshii]

Dave Tolls wrote:What Jeanne says.
You are not reporting to the scrum master (a common misconception, it has to be said).
You are keeping the team informed about where you're at with your work.

Do you means the developers and not scrum master will do the below ?

"purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work"

[Paul Clapham]

I think it's pretty clear. Dave is at least the third person to say that, there may have been more.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:

Dave Tolls wrote:What Jeanne says.
You are not reporting to the scrum master (a common misconception, it has to be said).
You are keeping the team informed about where you're at with your work.

Do you means the developers and not scrum master will do the below ?

"purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work"

The developers should be aware of how they are doing with respect to the sprint goal and make adjustments as needed.  Remember that the SM isn't in charge.

[Junilu Lacar]

The stand up is NOT a status meeting: https://www.scrum.org/resources/what-is-a-daily-scrum

In fact, the three questions cited are no longer really recommended because they often lead people to believe that the stand up is a status meeting and behave in ways that are antithetical to agility and self-organization.

Your standup may be a status meeting if:
1. Each team member is reporting their individual progress on their individual tasks to the Scrum Master
2. Team members are just saying what they plan to do today without any mention of who on the team needs to collaborate with whom.
3. Team members are just saying what's blocking their progress without anybody offering to help or escalate the problem

If your daily standup has any or all of the above characteristics, then you're not really being agile nor are you a self-organizing team. You're just a group of individuals working independently and feeding the "Scrum Master" your individual statuses.

For me, an effective standup is when
1. The team gathers around their board and discusses the progress of each item with respect to the sprint goal. They are talking to each other and are looking at their board and each card on the board.
2. The team plans on how they will collaborate for the next 24 hours until their next standup meeting
3. The team plans how they will help each other to address any impediments or who they need from outside of the team to help.

Any questions the team asks during the standup should be related to mainly these things.

[Satyaprakash Joshii]

Junilu Lacar wrote: without any mention of who on the team needs to collaborate with whom.

Some tasks would require lot of collaboration.Lot of tasks will require some collaboration.Few tasks will be independent ones which would require minimal collaboration.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote: and make adjustments as needed.

Adjustments like ?

[Junilu Lacar]

Satyaprakash Joshii wrote:

Jeanne Boyarsky wrote: and make adjustments as needed.

Adjustments like ?

If they find a story is too big, they may split it into two or more stories and move some of them out of the sprint, for example. Or if they are doing well, they can pull in another story.

[Satyaprakash Joshii]

I have seen that often the developers are focusing on the points they would be speaking on when their turn comes, so due being occupied with this they don't fully listen to what the other person is speaking.

[Satyaprakash Joshii]

Junilu Lacar wrote:
If they find a story is too big, they may split it into two or more stories and move some of them out of the sprint, for example. Or if they are doing well, they can pull in another story.

So this will be done by the developers.But if every developer starts speaking on this then there would be too many opionions.Shouldnt someone be there to have the final say in case of multiple opinions.

[Junilu Lacar]

Satyaprakash Joshii wrote:
Is below a right example on how one should update the status for an example user story  to create REST API to read data and then upload it on S3 using Lambda function?

That's not a user story. No user would tell a story like this. These are engineering tasks.

[Junilu Lacar]

Satyaprakash Joshii wrote:So this will be done by the developers.But if every developer starts speaking on this then there would be too many opionions.Shouldnt someone be there to have the final say in case of multiple opinions.

I was giving examples of what an "adjustment" that Jeanne alluded to might be. I wasn't saying that this is the only kind of adjustment that might happen or that it would happen every day and every developer would have to do it at every standup. You seem to be misconstruing what I said, to what end I'm not exactly sure.

Also, if a developer thinks the story they're working on is too big, they don't discuss the details and do the story splitting during the standup. Standup is not for finding solutions, it's for planning work for the day. What would happen is more like this: While working on the story, we realized that it's too big and it probably should be split (into N stories) instead. Can we get together after standup to discuss this? We'll need the product owner as well so we can discuss/negotiate which of the stories to keep in this sprint and which ones we can put back in the product backlog (to do in a later sprint).

[Junilu Lacar]

Your line of questioning tells me that you're still trapped in some kind of Agile Bizarro World where antipatterns are the norm rather than the exception.

[Junilu Lacar]

Satyaprakash Joshii wrote:
Do you means the developers and not scrum master will do the below ?

"purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work"

Case in point: if you think that's the job of the Scrum Master, then you're in the Bizarro World where a Scrum Master is really just doing the work of a traditional Project Manager. In that case, you're really doing traditional development, not Scrum.

[Junilu Lacar]

Satyaprakash Joshii wrote:
Is below a right example on how one should update the status for an example user story  to create REST API to read data and then upload it on S3 using Lambda function?

Yesterday, I worked on task XYZ and implemented the code for API which reads the request.
Today, I will work on the task ABC and implement the lambda function which sends this data to the S3 bucket ?
There is an impediment that I do not have access to create lambda function.Estimate for this is 16 hours.

This is not the way. A better way would be:

We've been working this story (pointing to the story card, say it's the "Create a new order" story, for example) but we can't seem to access the lambda function on S3. We need help figuring this out. Can someone spend some time with us after the standup to look into this? Since this might take at least another day to figure out and test, we might not be able to pick up another story before the sprint ends. Where does that leave us in terms of achieving our sprint goal? Or should we think about dropping one or more stories from this sprint? Let's talk about this in more detail after the standup to discuss our options and replan if necessary.

[Satyaprakash Joshii]

Junilu Lacar wrote:
We've been working this story (pointing to the story card, say it's the "Create a new order" story, for example) but we can't seem to access the lambda function on S3. We need help figuring this out. Can someone spend some time with us after the standup to look into this? Since this might take at least another day to figure out and test, we might not be able to pick up another story before the sprint ends. Where does that leave us in terms of achieving our sprint goal? Or should we think about dropping one or more stories from this sprint? Let's talk about this in more detail after the standup to discuss our options and replan if necessary.

Yes. But this talks entirely about the impediment part only.

[Junilu Lacar]

Satyaprakash Joshii wrote:

Junilu Lacar wrote:
We've been working this story (pointing to the story card, say it's the "Create a new order" story, for example) but we can't seem to access the lambda function on S3. We need help figuring this out. Can someone spend some time with us after the standup to look into this? Since this might take at least another day to figure out and test, we might not be able to pick up another story before the sprint ends. Where does that leave us in terms of achieving our sprint goal? Or should we think about dropping one or more stories from this sprint? Let's talk about this in more detail after the standup to discuss our options and replan if necessary.

Yes. But this talks entirely about the impediment part only.

So you didn't catch the part about what was worked on the previous day and what the plan was for the rest of the day? I think you're being a little bit short-sighted if you think that's all about the impediment.

But that's kind of beside the point. It seems you're still thinking about the standup as a status meeting. Again, it's not a status meeting, it's a planning meeting. The team should come away from the standup with a clear idea of what they're going to do for the rest of the day.

[Satyaprakash Joshii]

Junilu Lacar wrote:
Case in point: if you think that's the job of the Scrum Master, then you're in the Bizarro World where a Scrum Master is really just doing the work of a traditional Project Manager. In that case, you're really doing traditional development, not Scrum.

Yes.That is right.

https://www.scrum.org/resources/what-is-a-scrum-master

I read the scrum master improves team's effectiveness and helps in removing any impediment.

What kind of things may he do to improve the effectiveness of team ?

[Junilu Lacar]

Satyaprakash Joshii wrote:
What kind of things may he do to improve the effectiveness of team ?

Coach them that the daily standup is not a status meeting but a daily planning meeting.

[Satyaprakash Joshii]

Junilu Lacar wrote:
Coach them that the daily standup is not a status meeting but a daily planning meeting.

But this is something developers should already be knowing and even if they have to be told this , it is a one time job to tell this.

[Junilu Lacar]

Satyaprakash Joshii wrote:

Junilu Lacar wrote:
Coach them that the daily standup is not a status meeting but a daily planning meeting.

But this is something developers should already be knowing and even if they have to be told this , it is a one time job to tell this.

That is patently false. You came into this thread not really understanding this and we've had to keep repeating the point to you. Are you sure it's a one-time job? In my experience, it takes a while for developers to get it and they often fall back to a comfort zone of not being self-organizing and just giving a status to somebody. This is so deeply ingrained in some people's psyche that takes a while to undo and replace with a different mindset.

There are many other things a scrum master can coach the teams on that the team will need constant reminders about. Retrospectives, collaborating, making work visible, focusing on quality, etc. There are so many ways teams and team members can behave that is counter to agility. A scrum master's job is never done.

[Satyaprakash Joshii]

Junilu Lacar wrote:it takes a while for developers to get it and they often fall back to a comfort zone of not being self-organizing and just giving a status to somebody. This is so deeply ingrained in some people's psyche that takes a while to undo and replace with a different mindset.

Once one understands it once it is upto his level of professionalism to continue doing that or fall back.

[Junilu Lacar]

Satyaprakash Joshii wrote:Once one understands it once it is upto his level of professionalism to continue doing that or fall back.

That has nothing to do with the point about what the Scrum Master would do to help the team be more effective. I don't see where you're heading with this. Seems like you're just replying to have the last word.

[Satyaprakash Joshii]

Junilu Lacar wrote: Retrospectives, collaborating, making work visible, focusing on quality, etc. There are so many ways teams and team members can behave that is counter to agility. A scrum master's job is never done.

Yes I understand that retrospectives, collaborating are some of the key things that the scrum master would help team with. What does making work visible mean here? For quality what I understand is that code reviews by team leader or developers would help produce better code. In what way would the scrum master help with this ?

In addition to these , I think there is one more thing scrum master will do. That is to make sure that there are no factors which are causing time waste for any team member.

Overall I have got a picture of what the scrum master would do.

[Junilu Lacar]

Satyaprakash Joshii wrote:What does making work visible mean here?

It means making sure that team members are not doing any "hidden" work that's not related to the sprint goals. Everything the team members are doing should be related to a story that's on the board. In many work environments, team members can get pulled into other work that's not related to the planned sprint work. The Scrum Master needs to address that because it can easily become hidden work and that takes away from the team's actually capacity and ability to meet the sprint goals.

For quality what I understand is that code reviews by team leader or developers would help produce better code. In what way would the scrum master help with this ?

An astute Scrum Master can point out when code reviews are happening later than when they are most effective, which is what typically happens when teams don't collaborate and do things like TDD/BDD. The Scrum Master can point out these types of waste and coach the team or find a coach to help them adopt TDD/BDD and other practices that make code reviews more timely and effective.

[Satyaprakash Joshii]

Jeanne Boyarsky wrote:I invest in coaching new people on how to communicate better.

Could you please share what communicate better means to you. Hearing this from you would be valuable.