You are currently browsing the tag archive for the ‘scrum board’ tag.
Over the years using and implementing Scrum in organisations, I struggled sometimes with the value of the daily-standup…
Why did I struggle?
- The teams started off excited and it worked, however, as the adrenalin rush dissappeared, the daily stand-up became a drag, something they had to do with no excitement and not a lot of communication or team co-ordination
- By asking every member to come to the front and answer the 3 questions, there was no cohesive drive towards completing stories from the top ( prioritised ), people were all over the board and it was difficult to see what is what
- The communication as a team was not good, there was no hype, there was no excitement and no drive towards a mutually accountable goal at all…
The Solution
Well, this may go against the books and theory, however, it works for my teams…
I changed to ‘walking the board’, and a lot of Scrum practitioners are now doing the same…
I asked the team to communicate and co-ordinate collectively on each story, one at a time, from the top ( highest priority ) and talk through each story as a team…
The Result
It worked! I managed to solve 2 problems with this…
Problem 1: No effective communication and co-ordination as a team
Problem 2: Working all over the board, instead of delivering stories as a team from the highest priority first!
By walking-the-board we manage to solve both… the teams are now excited, they communication extremely well, the focus together as a team on their mutually accountable goal and the best is that suddenly they are holding each other accountable for that goal…
Since, I have used this regularly when I encounter the above mentioned problems… walking the board provides a Scrum Master or Coach with a method to mature an Agile team very fast…
Please go to http://agile-commentary.blogspot.com/2009/04/walking-board.html for another Agilist who did the same…
Kind regards
Arrie van der Dussen
Agile Business Manager
Kaizania
Estimating Tasks or Not? The effect of value driven user stories…
May 4, 2009 in Agile Commentary, Scrum Coaching | Tags: coaching, estimating, implementing scrum, scrum, scrum board, scrum product owner, velocity | by thinkingagile | Leave a comment
One of the perks of having a scrum coach in house regularly, is that my mistakes hardly ever go unnoticed . We have a regular meeting during which we discuss our own scrum implementation in Kaizania, and how we can improve the way we work. For me, this is one of the best things about scrum: you have never “arrived”, and can’t settle into a comfort zone, there is always something which can be improved!!
We had a meeting about a week ago, during which Arrie pointed out some things which we need to sharpen up on, one of which was the fact that we currently size our tasks, not only the stories as we’re supposed to. Now, even though I know it isn’t supposed to be done this way, we did it with good reason, and after having the discussion with Arrie, he understood the purpose of this, and left it at that.
The reason behind the unruliness was that we needed to size our tasks, as the stories took longer than a day to complete, sometimes up to 80% of the sprint duration, hence the burn down would be useless if we didn’t size the tasks. In the past we tried one sprint, without sizing the tasks, and it was chaos. The team attempted to estimate the work left during the daily stand-up, but their estimate was not even close to being accurate, and we ended up with a lot of work left two days before sprint end, even though the burndown chart indicated that we were well ahead of schedule.
To avoid running into that problem, we had the team size the stories during sprint planning, as it should happen. Afterward I, as scrum master, would divided the story size between the number of tasks, and so each task had a size as well (which made up the total points allocated for the relevant story). This gave us a much better indication of the progress made, and even though it wasn’t the perfect solution, it worked much better than estimating the amount of work left during the daily stand-up.
After my discussion with Arrie, we had a sprint planning, and one of the other areas which we had to work on was breaking our stories down. With blood, sweat, and some tears we managed to put together a complete sprint backlog with no story sized bigger than 13!! This was a huge improvement, as our previous sprints had stories sized as big as 89!!
Once we started doing the task breakdown, we realized that the tasks were much different than before, and there was no sense in sizing them anymore!
The problem was that with the bigger stories, we actually had an epic as the story, and the tasks were small user stories. During our first stand-up meeting, I explained to the team again how we do the estimation of work left, and this time around it went much better. Because our stories were smaller, the team was confident to size the work left, and this time around our results were much more accurate. Even more accurate than when we allocated a size to the tasks.
Danette Kok
Scrum Master
Kaizania