I attended your training class a couple of months ago. We are continuing along with our scrum process, and we are learning a lot. I have one question - hope it is ok to ask. We did story point estimation as part of our team's Sprint planning, and came up with the total story points that we were going to tackle for the sprint. As we started working on some of the tasks, we realized that they were more difficult then we had originally estimated. Also, some people finished their tasks early and picked extra stuff from the backlog.

My question is as follows: Do you ever change the total story point value in the middle of the sprint (for either of the reasons that I mentioned above), and it if so, how would that work if your burn down is based on story points vs time. I know we talked about it in class, but I can't remember the answer.

I remember asking my own Scrum coach the same question a few years ago.

A Scrum Team is:

• A Product Owner
• A Scrum Development Team
• A ScrumMaster

Let’s look at how a team makes use of task estimates. During Sprint Planning, teams create tasks and task estimates from the backlog items that they are potentially going to commit to finishing.

Organizations that are looking for an automated tool to help manage Scrum fall along a continuum.

• At one end are the Scrum purists, who feel that resistance to doing real Scrum is an organizational impediment to be exposed and rooted out rather than accommodated as business as usual. These folks believe the highest performance and ingenuity comes from intense collaboration, small cross-functional teams lacking defined roles, self organization, face to face communication, and even a certain amount of chaos during Sprint execution. They typically prefer lightweight tools that make the Scrum artifacts visible without impeding team self organization.
• At the other end are those who want some version of the Scrum/Agile practices, but also feel "traditional" practices (such as Taylorism, waterfall, or parts of the PMBOK) would meet their current needs. They may be dealing with impediments to self organization, lack of co-location, suboptimal team composition, large departments, entrenched practices, regulatory requirements, etc. Or they may not be in a position to wait for teams to go through the "forming, storming, norming, performing" growth stages. These folks tend to request features that make the purists cringe.
• Some are in organizations that are transitioning from traditional practices to Scrum. Some skeptics I've known became full-fledged advocates after seeing results from pilot teams attempting uncompromised Scrum with good coaching.

When I was much younger, it was explained to me that sticking my dad’s screwdriver into the electrical outlet was not a good idea. As a good little boy, I obeyed and convinced my older brother to try it, instead. Fortunately, we used an outlet at the end of a long hallway, so my brother’s resulting flight from the shock drew a clean and uninterrupted arc down the hallway.

I've finished my first week and my first class as a Danube employee and trainer.

I've collected a dozen Dilbert cartoons relevant to Scrum. This week brings us a couple cartoons depicting a dysfunctional daily Scrum (an exercise we sometimes use in class). Previous cartoons have lampooned user stories, working without plans or documentation ("Just start coding and complaining!"), and forcing Agile approaches from the top down.