I've got a great job!

Scrum is inspiring to me because it is one of the few management paradigms that seems to capitalize on the best of human psychology, yielding a result that is both best for workers and for business. Scrum can make work fun and, when you spend eight or more hours per day at work, it ought to be both challenging and fun (more on this in another blog).

If you asked a few people in the Scrum community to define Scrum, you might be surprised to receive a different answer from every person. To me, it’s a management paradigm, a set of guiding principles, a key to employee retention, the embodiment of good application of organizational psychology, and just plain common sense. But if you polled the same group about the basic mechanics of Scrum, you'd notice much less discrepancy among their responses.

Scrum’s mechanics have three major parts: roles, meetings, and artifacts.

A friend of mine, who was pursuing his doctoral degree in electrical engineering, once tried to explain his dissertation to me by showing a program he wrote, walking me through the code line by line. I'm not an engineer, so I had no idea what he was talking about. But because he was immersed in the terminology of his field, he found it was hard to explain his work to an outsider.

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.

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.

For many managers adopting Scrum, one of the hardest traditional project management practices to leave behind is tracking hours spent. It’s not hard to let go of because tracking hours is essential to effective management, but because Scrum’s tenets of self-empowerment and transparency are in direct

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.