- Josh, Limit your stories in progress. Swarm on a story at a time. If your team lacks the discipline to finish a story before starting another then try usingMessage 1 of 6 , Oct 7, 2010View SourceJosh,Limit your stories in progress. Swarm on a story at a time. If your team lacks the discipline to finish a story before starting another then try using WIP limits - aka Kanban. This is how Kanban makes Scrum better - with explicit WIP limits that the team respects.Better to end a sprint with 2 stories done than 4 stories half done. In the long run you'll get more stories done by limiting how many are in dev at a time. Hope that helps.
Sent from my iPhone
On Oct 7, 2010, at 11:45 AM, "Steve Ropa" <theropas@...> wrote:Hi Josh,I have indeed observed this behavior many times my self. One thing that jumps out to me right away is that you mention "sometimes we are assigned tasks....". I like to see team members sign up for tasks, rather than receive assignments. If we can, as a team, agree to only sign up for the top priority story's tasks until that story is done, we will see a lot more throughput on "done". Folks will be able to "jump in" more as they are already working together on that story. It is absolutely true that the lower value stories, as defined by the product owner, will be "at risk of non-completion", but honestly right now *all* of the stories are at risk of non-completion.I'm not sure I'm 100% on board with rotating the scrum master, but if you can't have a dedicated full time scrum master, this is a workable compromise.It looks like you know your stuff here. Rely on that understanding as you help your team move the ball.SteveFrom: JoshSent: Thursday, October 07, 2010 7:04 AMSubject: [scrumdevelopment] Daily Scrum Patterns and Anti-Patterns?
I hope you're all doing well. In our team, we have about 16 to 20 people. For a while we had separate, smaller teams, but we've lost some QA people and it was getting hectic for people to have to attend 3 stand ups every morning.
It's been my basic understand of Scrum, being named after rugby and the "huddle" and "moving the ball down the field", that the main objective of a stand up is for the team to discuss how, as a unit, they are collectively advancing the highest priority stories toward completion.
And, ultimately, the goal should be to get as many stories to 100% completion rather than striving to get as many stories to "started" or "in progress" if they're only going to end up at "80% or even at "99%" completion before the end of the sprint.
Am I right or wrong here?
What I've started to see in our own team is a focus not on the top priorities of the team, but a round-robin delivery of what each of us individually is doing on our own individual story lanes.
That is: we start in no particular order at all with regard to "highest priority" stories, and just speak a few sentences, without touching the board or moving anything physically across. Often, the highest priority story ends up with one person working on it and he or she ends up spending Crazy Overtime until all hours of the night working to Git 'Er Done. It seems that there is fear in the team from the rest of us to say "Oh, do you need help?", because asking that would put our own individual, perhaps lower value, stories "At Risk of Noncompletion", thus risking feeling like a "non performer" or "underperformer".
Often times we are assigned tasks before we plan, and we are given stories that already have "Points" attached to them. This has changed toward a better direction lately, though.
But....I'm curious, what are other people's experiences like?
In my past experience with Scrum, the most effective morning stand ups operated like this:
1) Our team rotated the role of Scrum Master each sprint.
2) We had a great big huge Scrum wall with lanes. The highest priority work item was at the top of the wall in its own lane.
3) In the morning, our scrum master would ask us what we've been working on, pretty much round-robin style
What really sunk in for us was when our QA lead Mark, who had done scrum for 3 years longer than any of us, stopped us and pointed to the top priority story and asked, "What's happening with this? Nobody said anything about it. If we've identified this is as the highest priority, then we need to discuss it and why it's not moving. Is it impeded? What can we do?"
From that point forward, we tended to address the scrum by starting with the board, not with the people. We'd look at the wall, go up to the wall, physically move things, usually starting at the highest priority lane.
This was most effective to me, because we often "jumped in" and helped each other or saw opportunities to help or to defer lower value stories when someone needed assistance on the higher value items.
Anyway...just curious on other's advice and experience too.