The Agile School

http://thenetschool.blogspot.in/2012/06/databasefactorycreatedatabase-error.html

Last few days many have asked me about the roles & duties of a Scrum Master ( and some even the need of an SM in organization ). Following is one of the best checklist which I could find. I am willing to help anyone if they need further clarifications. A ScrumMaster’s Checklist Posted by Michael James on August 13, 2007 An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen. But if you can envision a team that has a great time accomplishing things you didn’t previously consider possible, within a transformed organization — consider being a great ScrumMaster. A great ScrumMaster can handle one team at a time. We recommend one

• I can push bugs to backlog. • We can complete a story without fixing all the bugs • I have to finish all the stories first; the bugs can be fixed later. • Before the release I will have a maintenance sprint which will have only bug fixes. The list is big. If you are doing anyone of the above please stop doing it before it is too late. One of the fundamental requirements of scrum is to have a shippable product by the end of the sprint. There is no benefit in "finishing" maximum stories with lots of bugs. Scrum places high importance in the quality. With this approach of not fixing bugs will lead to accumulation of bugs & in few weeks you will have 100 + bug and you may spend couple of months fixing it. The cost of pushing bugs sprint after sprint will increase exponentially. The bug which could have been fixed in 30 minutes today will take couple of hours after 2 months!!! I have faced this problem in many teams I have worked with. My simple advice is to sl

This is a great article by  Jose Luis Soria One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of“forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications. Read the full article @ http://www.scrum.org/commitment-vs-forecast

I talk a lot about scrum. Many times when I speak I hear people saying that they are also doing scrum and they have daily scrum status updates. No other ceremony is so blatantly misused. It’s a misconception that scrum is only about stand ups. I have seen a project manager doing a scrum update with a big team, the status update itself took 1 hour, and the information passed was so huge that nobody remembers anything. By the time the last person updated his “status” the first person would be sleeping. Starting a daily meeting and asking for status update does not falls under Scrum. Many are thinking about “what are the scrum meetings rules” rather than thinking about “why do we need this meeting”. I prefer calling this as Scrum Planning meeting. This is the planning meeting for the day. I can add the following objectives to the meeting To see if the team is on the correct path, will they complete the committed task if not what changes should be made to accomplish the objective.  D

Following are some of the rules which I could think ( & found from other sources) regarding the daily Scrum planning meeting Scrum meeting should be for a small team of 4-8 members. Having a meeting for a bigger team is not beneficial. There is a high risk that it will become a status update. This should be a timeboxed meeting of around 15 minutes.  Hold the Daily Scrum in the same place at the same time every work day. The best time for the meeting is first thing in the day so that Team members think about what they did the day before and what they plan to do today. Stand up – Ensure that team members are standing for this meeting. This will ensure that meeting will not exceed the normal duration as people will be eager to sit down. This will also help to focus on the discussion  otherwise people may get distracted with email or other “tasks”.  Team members should address the Team. This is not a "Reporting to the Scrum Master" meeting.   If Product Owners are a

A story of Agile transformation @ salesforce.com 94 % Increase in feature requests delivered - 2007 v. 2006 38 % Increase in feature requests delivered per developer - 2007 v. 2006 Read the following slide for some more staggering data!!! http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation