Some Advice On Scrum

Pre-Planning

The first step in the sprint is the planning meeting, where the development team and the product owner prioritize the tasks in the backlog, estimate them all, and assign some of them to the current sprint. These are admittedly a lot of tasks for just one meeting, so the meeting can take a lot of time and also wear out everyone participating in it.

If this is the case you can use a pre-planning meeting where the product owner can prioritize several tasks in the backlog and then the development team alone can estimate, and assign them to the current sprint.

That way each meeting has a sole purpose to focus on, i.e. pre-planning tasks prioritization and planning tasks estimation, and each will also take less time to complete.

Daily Meetings

Usually in a daily meeting each member of the development team will talk about what they have been working on, what they will work on for the rest of the day, and any problems they may need to discuss. But the meeting leader shouldn’t enforce any order or structure, they should just remind the team members of the topics in case someone doesn’t stick to them.

The meeting leader should keep the conversation as natural as possible. This is important because the team members may have something important to say, but if a strict ordering is imposed on them, they might forget how to accurately phrase the important message or even worse, they could forget what they were going to say altogether.

Retrospectives

Retrospectives are good, but they have one problem. Retrospectives are like a policeman questioning a crime witness a week after the crime was committed.

During the sprint the team members will probably stumble upon problems that deserve to be mentioned in the retrospective meeting. These problems should be discussed on a daily basis (another topic for daily meetings), so that the person reporting the problem has a fresher memory of the issue and key points are not lost. Another benefit of discussing issues as they come up is that the team can find a better solution based on more accurate information. Now you have a solution that you can implement, and you can test it that same day. After all, we are agile.

The retrospective meetings will still serve the same purpose of bringing up problems experienced during the sprint, and coming up with solutions. The difference will be that part of those problems are already taken care of because they were discussed and likely fixed during the sprint. You can also discuss whether the solutions to some of the problems were effective, and if they were not, propose new ones for the next sprint.

Points System and Developer Experience

The scrum estimation system is based on points, while the scale is up to the team. Those involved in the estimation process must always remember that these points represent effort.

Teams are used to applying the Fibonacci scale for estimations. This scale begins at 1, so it is recommended to have a pool of tasks estimated at 1 point because you can use them to make better estimations based on the least amount of effort a task requires.

You may argue that an experienced programmer can estimate a task lower than a novice one. But that is OK, and probably won’t give the sprint a false velocity, because if the task is a difficult one the more experienced developer will take it and leave the easier ones to the novice developer, or at least until the latter gains more experience.

Points Signify Effort, Not Hours

Let’s suppose we have a team with these characteristics in the current sprint:

• Number of team members: 6 developers
• Work hours per day: 8 hours/days [h/d]
• Sprint duration: 7 days [d]
• Current velocity: 48 points [pt]

With this data we can start answering questions:

1. How many points can a developer complete per sprint?
2. How many points can a developer complete in 1, 4, 8, 16, 24 hours?
3. How many hours does a developer need to complete a 1, 2, 3, 5, 8, 13 and 21 points?

A. This one is really easy. Our team has a velocity of 48[pt] and it has 6 developers so we just need to do the following:

So if we round the number we get 8 points per developer per sprint.

B. Now that we have figured out that a developer can complete 8 points in a sprint, let’s calculate how many hours the developer will need to finish 1 point.

This means that a developer of this team will be able to complete approximately 1.1428571429 points per day. We know that a developer works 8 hours a day, so we can replace [d] with 8[h].

What we’ve just figured out is that a developer will be able to complete 0.1428571429 points per hour. So if we multiply we get the other values we are looking for:

C. Now we are going to use the ratio we obtained in point B, but we are going to invert it so we can calculate values based on points rather than hours. Our ratio will end up being:

The following is simple, we multiply by points.

We previously calculated that a single developer could complete 8 points per sprint, and as you can see in the fifth row from the top a developer can complete 8 points in 56 hours, or 8 hours each 7 days.

We can thus conclude that points can be translated to hours, although keep in mind that it’s not a fixed ratio since it depends on the velocity of the team.