I recently received the following question from one of my students:

"I manage a project using Scrum but the team is limited to 40 hours/week, not a minute more, due to contractual obligations. According to Ken Schwaber, Scrum relies on personal commitment - folks
will do what it takes to succeed. How do I best use Scrum in this environment?"

Situations like this are less than optimal, but not really rare, either. Contract programmers love to do what it takes to finish the job, but they will rarely do so without filling out that time-sheet with all the extra hours, either. That works OK if you're in a situation where more revenue is generated the earlier the work is finished. However, if the revenue is fixed and the time frames are variable, the additional expense is no one's friend.

I warn many of my students at the beginning of CSM classes that some of what they hear during the class may some counter-intuitive. I’m concerned that there are “truths” they’ve “grown-up” believing and practicing in the development of software applications that may lead to trouble during the class.

Today, I chose to write about one of those questions that I’m asked over and over again in my CSM classes and coaching opportunities: “Why is management so different in an Agile organization than in any other?” I decided that I was going to find out.

I've had the great privilege of learning about Open Space meetings from one of the best practitioners in the business: Diana Larsen. One of the principles of Open Space meetings is that "whatever happens is the only thing that could have." Assuming that our Scrum team is working in good faith (which is to say, doing the best they possibly can), I believe that this Open Space principle is true for Sprints as well.

(I'll add to this post more in the near future, but I wanted to get it started based on an email I answered for a student of mine.)

As for creating a definition of DONEness, my recommendations would be as follows:

1. Get as many different examples as you can find of DONEness definitions. The more material you have, the more complete your first version can be.

How much your team is willing to commit to during any Sprint is going to depend on a lot of things, starting with how comfortable your team is with not achieving all of the planned results. Many Scrum teams will deliberately under-commit because they work (or are under the impression that they work) in an environment that frowns on not achieving their objectives as stated.

Capitalization of a software project is extremely important to organizations engaged primarily in application development these days. To put it simply, the US government allows a company to defer the taxes that would normally be paid on research and development activities until such time as the product is generally available and the company can begin selling the product and bringing in revenue.

If a user story isn't completed during a Sprint, the cleanest way to deal with it is to leave the story point value as is and return it to the Product Backlog.

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.

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.