Günther Gerlach

written by gunther gerlach-2011

This is a list of the most common mistakes that I have seen again and again along my career in small and large corporations in their intention of implement Agile as the primary development process. I hope while you are reading this, help you to understand what is the logic behind every single practice and try to adapt (shape) to fit into your environment. Remember, the goal is not just follow the best practices but to achieve the goals behind each one. 

 Read more…

 Daily Scrums

Gunther Gerlach

written by gunther gerlach-2009

Velocity is a measurement of how much the team gets done in an iteration (called as Sprint in Agile Scrum). Velocity is what actually got done in the last iteration not what is planned and is calculated by the number of story points done in a certain sprint.

In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

Examples are 1, 2, 4, 8 , 16

Gunther Gerlach

written by gunther gerlach-2009

An XP practice where two programmers work alongside each other, trying to get a task accomplished. Two minds at one problem!

How this help?

·         It brings up productivity if the pair knows what it is up to. A chatty pair can cause more damage to the project than getting done

·         It keeps each person honest. If you don’t know something its apparent in the fifth minute.

·         It helps keep the quality of the code. Since the pair is helping code.

·         This is where design happens.

Gunther Gerlach

written by gunther gerlach-2009

Story points are used to measure the effort required to implement a story and is measure based on Size, Factorial, Squares or Fibonacci techniques. This is a random measure used by Scrum teams.

This is mainly done as we as humans and as managers are better at abstract terms. If we use hours as a way to size stories, then the managers in the room have questions, teams don’t immediately feel comfortable with hours…

Gunther Gerlach

written by gunther gerlach-2009

How it works: Select a regular time period over which to measure project velocity. If you’re using fixed Sprints or iterations, use that time period. Otherwise you can use weeks, fortnights or months. It doesn’t really matter which as long as you’re consistent. Add up the estimates for all the tasks/deliverables/features in your chosen time period. It doesn’t matter whether the estimates are in days, hours or even in relative story points. Only include the estimates for any items that are 100% complete and signed off within the time period. Anything still in progress counts as zero, as there is no value in incomplete work.

Gunther Gerlach

written by gunther gerlach-2009

There are many approaches for the estimation of a project. Some people will tell you to use the estimation based on story points from Fibonacci numbering system, however this approach only work when features are similar enough to keep a project velocity chart (average project velocity per sprint) in your project but, we all know that this is impossible, some features will need less than a hour of development and other sometimes two days. I am not saying that this methodology is not good, I am just saying that is perfect to get your project velocity chart from the project but if you really want an estimate to get the cost and scope from your project you need the estimate in a period of time, usually days of work.

Gunther Gerlach