The Agile School

Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified...

I like user stories a lot. They help everyone talk the same language and results in a better product. User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. ...

In one scene of the TV show Mad Men , a young advertising copywriter (Peggy Olson) asks her boss (Don Draper) how to know which of her advertising ideas will work best. He tells her she can’t know in advance, which frustrates her. He then adds that part of her job is “living in the not knowing.” Part of our job, too, is living in the not knowing. To survive--perhaps even thrive--here in the not knowing, we need to become comfortable with uncertainty. That means we can’t: Know six months in advance exactly what will be delivered on what date and at what cost Know exactly how much more productive one team is than another Know how users will respond to a feature before they see it Similarly, we can’t even really know things such as that velocity will go up when a good, new member is added to the team. It should, but it’s not guaranteed. I can think of at least a couple of situations in which adding a good person to the team reduced velocity for more than the first f...

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 ...

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