Scrum Standup Format Enhancements

We have been using Scrum for several months, and I have never felt that I am benefiting greatly from a standing meeting. When I leave the booth, I want to feel that I know exactly where we are in this sprint, and that we are at the top of priority tasks.

We carry out the standard three questions, but since we go personally to the person, there is no real conversation about where the user's actual history stands, since several people work simultaneously.

For the last sprint, we tried to change the format and look at each task in order of priority. Each person answers three questions based on this task if they work on it. This gives us a better idea of ​​the current state of each task and ensures that we will work on the right things ...

Does anyone have experience in this matter and any better solutions?

+6
scrum agile
source share
6 answers

What works well:

1) Work with a small team

3 to 5 people are nice. Above 7, constant meeting no longer works.

2) You complete the "standard 3 questions".

When one person speaks, others can respond, and couples can form at that moment. For example, I say, “I will work on story A, and I want someone to help me with Ruby on Rails,” and then another person may say, “I will do this with you, right after meeting at the counter.” When it was the turn of this other person, she would say: "I did it ... and today I will work with Bernard, as we just agreed."

The main goal is to create pairs of people who will work together on the same tasks.

3) Then you look at the taskbar to make sure that the main question is during a standing meeting. Perhaps you can customize what you said if necessary.

It all takes about 15 minutes

I hope for this help.

+2
source share

When I leave the stand, I want to feel that I know exactly where we are on it in the sprint and that we are at the top of the priority tasks.

Daily expectations are not designed for this.

You want to discuss what you need to work on and with what priority at the Sprint planning meeting, and you will start working on them in priority order. You need to use the problem tracker to find out where you are in the sprint and see how the team works.

+2
source share

A burnt chart should show you progress.

It seems that you are a team manager or trying to micro-level a team. This is not allowed in Scrum.

At Scrum, the team decides that it should work. I understand your fears that the team may not fulfill what it did for Sprint, but in order to create a successful self-organization group, you must let it fail once. You should not be afraid of failure, and the team should not be afraid of being punished.

Since you have been using Scrum for only a few months, there is a high probability that the team will intercept. If a burn-out chart shows that the team cannot complete all the items selected for the sprint, the product owner should help the team decide which items should be removed. There is a chance to drop less important ones.

Once again - if you force the team to select tasks according to priorities during the sprint, you will kill Scrum.

+2
source share

This is a very simple change that I have been making for a while.

  • This is what I found out yesterday.
  • This is what I hope to learn today.
  • I need help to find out.

Everything else should be visible on the board / diagrams already (blockers go to red sheets).

When evaluating training, we end up going around information that is truly new to at least some people on the team, and we create an environment in which he cannot know everything, so training can take place.

+2
source share

Does anyone have experience in this matter and any better solutions?

I read several articles about this type - When team members give zombies answers to 3 questions, when there is very little cooperation and synchronization, when everyone talks about individual tasks, but not about their dependencies, when Team members do not offer to offer a solution for another task of team members Having heard their update, when everyone gives his report on the status of SM, and not the rest of the team, you know that your daily Scrum meeting is losing effectiveness.

Why does all this happen to the Scrum team? Well, it could be because SM follows “command and control” in the team, or your team is not sufficiently motivated, or the team believes that the “Daily Session” meeting is a waste of time, or the team does not like to cooperate and so on.

Due to the way you described your problem and commented on some of the answers of other members, I think your real problem is Command and Control. You must allow yourself empowerment. You must let go of the team members, but adhere to the principles of Scrum. Leave cooperation with the team, do not force cooperation. Tasks should not be “assigned” to the developer specified by you, team members must decide for themselves. Team members lose motivation if you try to control them, therefore, a dysfunctional Meeting at the IMHO stance.

+1
source share

I think the goal of Scrum is to identify blocking problems and who needs to talk to whoever solves them. Do you use story / quest cards? Progress can be appreciated at a glance if you ...

0
source share

All Articles