This starts off with Planning poker
Google Conference: Agile Estimation with Mike Cohn
An informative article on how to hold the Daily Scrum Meeting.
The Daily Scrum is simple daily routine to help the team self-organize, focus, and identify and eliminate impediments to progress. How do you conduct the Daily Scrum and how do you know if the Daily Scrum is achieving its purpose?
I came across this article by Mike Hadlow via Twitter. I found that I could relate some of what was described in the article to my own company. It is well worth a read
“Once the software gets part a certain size and age, it becomes almost un-movable and a real hindrance to the business. Often the response is to start from scratch, but this just makes things worse as the new system gradually goes the same way as the old, and in many cases never fully replaces it. Then there is the additional task of integrating the old and new systems, usually as a ‘temporary measure’”
I have found the issue of producing a substantial piece of functionality with a tight deadline an issue with Scrum. I shall set the scene. We conducted our Quarterly planning and prioritized our work for the Quarter.
A few days before the Quarter began a new piece of functionality was dropped on us from a great height. The deadline for this piece of functionality was 1 month away. We knew that it would hit us soon, but not as soon as it did. It was a high revenue earner and due to the fact that it was to be completed within one month it took precedence over all.
One problem with this new piece of functionality is that it is deemed to be greater than one months work. Also it is .Net heavy, so the Flash developers in our team will be light. So the Product Owner will need to promote stories for them to work on (Cross Skilling was an option, but we have some Flash work that needs completed this quarter anyway).
The second problem is that we have moved to a new 3 week sprints. We have no idea of our average velocity as we have just made the transition to 3 week sprints. Our average velocity for 2 week sprints was 31 Points but we have yet to find our average velocity for 3 week sprints.
The Third problem is that we have 1 full iteration and 1/3rd of an iteration to complete the stories that have been identified. For the sake of visibility and to gauge whether we are on track or not, I have added all of the stories to the Story Wall.
I have a feeling that this has turned into a Mini Waterfall / Scrum method in some aspects of development. As all of the stories need to be worked on and pretty much completed within this Iteration. I have to put all of the stories on the wall as I feel that this would give us better visibility of what we have done, what we are doing next and what we have still to complete and will help us as we know exactly where we stand. Also with all of the stories visible on the story wall, I am able to create my Burndown Chart to map if we are likely to meet our deadline or not.
We cannot really be iterative in development as we have to have the work completed in one iteration. We have prioritized the ordering of the stories on the wall with the most important at the top of the board so we are completing the stories in a logical order but the main worry for me is the Teams Velocity. I have always been under the impression that you should use your average velocity wisely. If you manage to complete more story points you should adapt your velocity to map this and on the flipside if you complete less story points you should adapt your velocity to account for this for the next iteration. We have a case where we need to complete nearly double our average velocity for 2 weeks, in a 3 week iteration to meet the hard deadline.
How do you guys feel about this. Is this an effective way of working?
If you work as part of a Scrum Team, then you would have heard these words at some point in time. I can guarantee you!
“There are too many meetings during an iteration and we cannot get enough work done”
Here is an article that tries to deal with this.
How do you try and deal with this within your own team?
A certified Scrum Master course for me was a great experience and really boosted my confidence when I returned back from the course to work with the Scrum Team. It was a different learning experience than what I was used to as it gave me a practical take on Scrum and also the knowledge needed to put my training into practice. I read the article that I have linked below that outlines what a Scrum Master should know after a CSM training course. It is very interesting and I can say that I have learned a lot, but in regards to Scrum, it is only the tip of the ice berg.