Scrum Standup Format Improvements [closed]
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this questionWe have been using Scrum for a few months and I have never felt that I get a huge value out of the standup meeting. When I leave the standup, I want to feel like I know exactly where we're at it in the sprint and that we are on top of the top priority tasks.
We do the standard three questions, but because we go person to person there is no real conversation as to where the actual user story stands since multiple people are working on it at the same time.
For the latest sprint, we have tried reversing the format and looking at each task in order of priority. Each person answers the three questions based on that task if they are working on it. This gives us a better feel for the current state of each task and ensures that we are working on the right things...
Does anyone have any experience with this sort of issue and have any better solutions?
What have seen working quite well:
1) Work with small team
3 to 5 persons is nice. Above 7, standing meeting does not work anymore.
2) You do a round of the "standard 3 questions".
When one person is talking, other can answer and pairs can form at this moment. For instance I say "I will work on story A, and I want somebody to help me with Ruby on Rails", and then another person can say "I will do that with you, right after the standup meeting". When the turn comes to this other person, she will say "I did that... and I will work today with Bernard, as we just agreed".
The main objective is to create pairs of persons who will work together on same tasks.
3) You then review the task board, ensuring you covered the main point during the standup meeting. You can maybe adjust what you said, if needed.
All this take about 15 minutes
Hope this help.
When I leave the standup, I want to feel like I know exactly where we're at it in the sprint and that we are on top of the top priority tasks.
Daily standups are not exactly meant for this.
You want to discuss on what to work and with what priority in the Planning Meeting for the Sprint and you start working on them in the priority order. You need to use a issue tracker to know where you are at in the sprint and see how the team is doing.
Burn down chart should show you the progress.
It seems that you are the manager of the team or are trying to micromanage the team. This is not allowed in Scrum.
In Scrum the team decides on what it should work. I understand your concerns that the team may fail to deliver what it committed for the Sprint, but to make a successful self-organizing team you have to let it fail once. You should not be afraid of the failure and team should not be afraid to be punished.
Since you are using Scrum for only a few month, there's a high probability that the team will over-commit. If the burn down chart will show that the team will not be able to complete all items selected for the sprint, the Product Owner should help team to decide what items should be dropped. Here is a chance to drop less important ones.
Once again - if you will force team to select tasks according to the priorities during the sprint, you will kill the Scrum.
This is a very simple change which I've been making for a while now.
- This is what I learnt yesterday
- This is what I hope to learn today
- I need some help to learn this.
Everything else should be visible on the board / charts already (blockers go on red stickies).
By valuing learning, we end up passing around information that's truly new to at least some of the people on the team, and we create an environment in which it's safe not to know everything, so learning can take place.
Does anyone have any experience with this sort of issue and have any better solutions?
I have read some articles about this kind of a topic - When Team members give zombie like answers to the 3 questions, when there is very little collaboration and synchronization, when everyone talks about their individual tasks but not about their dependencies, when Team members don't offer to suggest a solution to another Team members task after hearing their update, when everyone gives their status report to the SM and not the rest of the Team, you know that your Daily Scrum meeting is losing it's effectiveness.
Why would the above things be happening to a Scrum Team? Well, it could be because the SM follows a "command and control" on the Team, or your Team is not motivated enough, or the Team believes the Daily Scrum meeting is a waste of time, or the Team does not like collaborating and so on.
From the sound of the way you described your problem and commented on some other members answers, I think your real problem is "Command and Control". You have to allow self empowerment. You have to let go of the Team members but hold on to Scrum principles. Leave collaboration to the Team, don't force collaboration. Tasks should not be "assigned to" a developer as quoted by you, the team members should decide this on their own. The Team members would lose motivation if you try to control them, hence the dysfunctional Stand up meeting IMHO.
I think the goal of Scrum is to identify blocking issues and who needs to talk to who to resolve them. Are you using story/task cards? Progress can be assessed at a glance if you are....
加载中,请稍侯......
精彩评论