Comment: Changes to work forms an interesting tension.  At a fine grained detailed level it changes all the time. Each person’s individual to-dos often change to reflect their understanding of what it takes to get the job done. As the level of granularity increases to task then it is a change to the team’s plan. If the number of changes is significant and adds up to more than one story’s worth of work then you better stop and adjust your plan, usually you want the product owner in on that discussion. And if there are several new  stories that were  suddenly found and are so important they must be done right now, then call a stop and reset your entire sprint with a sprint planning session. Generally, the commitment by the team to the sprint should not change. Note: definition of team makes this an interesting discussion. Bottom Line: The goal here is to help the team get better at  expressing work they can do and following through on a commitment.

Yes, the process will take care of itself we don’t need to watch it that closely. After all, it’s common sense!

Comment: Of things to watch out for and not allow this is high on my  list.  It boils down to this rule: If the team is not doing a retrospective then they are not doing scrum. The retrospective is where the team takes formal ownership of their process. In these situations I crack shins, and kick knee caps and generally do what is necessary to ensure they continue doing a retrospective. Without that we often see teams fall into “it’s not my fault”  because “x” told me to. In some cases “x” is the process that no-one owns, imagine the process that gets created by someone who decides to own it but, does not do it themselves!.

Retrospective is an external constraint that must be demanded of the team. There are many ways to run a good retrospective, ScrumMaster rise to the challenge and support your team.

Here is round 2.

This is close to a done draft.

Please read and comment.

                                               Scrum In A Nutshell – Quick Summary

Download Scrum In A Nutshell

excerpt… “While the Stakeholders are the most important people for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is held accountable by them for the success of the Team. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.”

• How much is the PO truely seprate from the team?
• Is there a single wringlable neck?
• Is the team / PO a symbiotic ecosystem with a centralized model for detemining direction? thoughts?

This is free for you to consume. It is our hope that you will provide comments and feedback. Those that do can register on our community site and provide constructive comments. They will be acknowledged. We will use your comments to evolve the explanation of thought here or clarify ideas. As you read, hold on to your shoes because each sentence is loaded with deep layer focused meaning and if you skip around reading this will hurt your understanding. 

Thank you

Dan & Doug