As a team transitions to using Scrum and Agile, finding the proper sprint duration is likely something they will not give enough thought to. The team will likely just pick an arbitrary duration and set about to make that work. That is certainly one way to do it, but there is a real danger that this initial sprint duration becomes the norm without a second thought. I would caution against this idea. I find that it is important to understand how the scheduling works for sprints, and what a sprint of a given duration actually contains.
This blog is a continuation of the blog that I wrote about the importance of difficulty based estimations in the sprint process. In that blog, we covered how I feel it is important to distance the team from thinking in terms of time and to think of difficulty instead. Naturally, the next question to answer is: “How do I use those metrics to measure the burndown, and to a greater extent, the velocity of the team?“
Scrum, the most popular Agile Process according to Kenneth S. Rubin's bestselling book on Amazon ‘Essential Scrum’, helps teams create a more efficient methodology through an iterative and incremental process. A major goal for any business is to not only satisfy the customer, but also keep them happy. By following these simple SCRUM guidelines, a team will always put a functioning, quality product in its customer's hands after every sprint, therefore keeping them happy.
Team Foundation Server is an Agile tool that can help you organize your daily activities such as tracking big picture items as well as smaller ‘to-do’ tasks. I use TFS to track .NET software development projects, but I decided to try it to plan my daily activities for today's blog post. Read further to learn how I created a TFS process for everyday use.