Team velocity is the measurement of the rate a team can complete their stories in one sprint. Velocity can be measure by story points, backlog items or features, etc. In our department, we are using story points to measure velocity. Story point is the estimation of the size of the story. If the team thinks that a story can be done within a couple of days we will assign 1 point for this story. 3 points for medium size and 5 for large. If the story is larger than 5 points then we have to break it down and make it small enough such that the team can complete in one sprint.
Every team’s ability is different and each team’s story point estimation will be different as well. In Agile, velocity is used to project how many more sprints a project can be finished. In order to have a more accurate projection of the project’s end date, team velocity needs to be consistent and predictable.
How can we control our team velocity to be consistent sprint after sprint? This is not an easy task because velocity can be affected internally or externally. Sometimes Team velocity is affected by reduced team member’s capacity. Team members are not always working 100% capacity because there might be unexpected meetings, sick leaves, holidays or vacations. As a Scrum Master, you have to monitor closely to your team’s velocity. As I said in my previous post, retrospective is important for team improvement. During your team’s retrospective, you can also talks about team velocity. Is our velocity increase or decreased? If velocity is dropped, why it dropped? If the decrease in velocity is not due to reduction of team members capacity then probably there should be a problem need to fix. This is something as a team needs to discuss in the retrospective and find ways to improve and keep the velocity to be much more predictable.
Some organizations use team velocity as a metric to compare team’s performance. To my opinion, velocity should not use to compare among teams. It should just use as a metric to project the project’s end day. Story points estimation is different among teams. Some team thinks that a particular story needs couple of days to finish but another might think that it requires weeks. This discrepancy will affect the velocity of the team. If both teams have the equal numbers of members and they are both 100% capacity. One team will end up with higher velocity because they estimate the story with more story points. If we use velocity to compare teams then teams might find ways to make up the velocity to looks good. This will result in wrong representation of the velocity and this number will be meaningless.
In Agile, we pull out stories from the release backlog and work on it Sprint after Sprint in an iterative way. One of the advantage by doing this iteratively is because customer’s need is keep changing and we need to keep adjusting what we will be working on for each Sprint to accommodate this.
Product Owner prioritize stories in the release backlog is based on customer’s need and they have to make sure what we develop is what customers wanted. We do Agile is to improve how we deliver our products quicker, better and solve customer’s pain points. On the other hand, we also need to improve ourselves to be a better team in order to complete our stories in a consistent fashion and of course with high quality.
In order to improve ourselves we have to take seriously in our Sprint Retrospective. Please don’t think that Retrospective is just one process in Scrum that need to do for Agile Development Process. It’s actually a very important ingredient in Scrum to lead your team to the next level.
Do you realize that we don’t allow managers to be involved in Sprint Retrospective? The reason behind this is to make sure every team members can express himself or herself freely during retrospective. They don’t worry about complaining anyone in the team not performing. They don’t worry about being uncomfortable if he or she being criticized. They will point out everything that’s not working in the team and need to improve. This is the beauty of Sprint Retrospective! However, pointing out all the flaws in each Sprint during Retrospective is not sufficient. We have to take actions to improve. In our team, the very first thing to discuss in our retrospective is to follow up out previous Sprint’s action items. Making sure what we pointed out that is no working from the previous Sprint has been resolved or improved.
To become high performing team? That’s one piece of the puzzle definitely need.
Today my Indian visa is ready for pickup; however, at the same time my India trip is also cancelled. I am always optimistic and I believe this trip eventually will happen. I am getting the six months multiple visa so if I am allow to go in the next fiscal year, this visa is still valid. 😀
This is my lovely Indian visa.
BTW, this blog will still be alive and I will keep blogging no matter what happen to this trip.
This morning I am going to get my Indian Visa. I am at the Vancouver Downtown Indian Visa office right now. This office is pretty empty and I guess not many people going to India during summer time. I knew that this week in Chennai is like 43c and feels like 50c? Really wants to experience how it feels like 50c. Btw, Indian Visa is more expensive than my Canadian password $144.56 for a 6 months multiple visa; however, I am allow to smile in this visa photo not like the police mug shot I took for Canadian passport.
One of the Scrum Master’s daily activity is to remove team’s roadblock. If there is no roadblock does that mean Scrum Master will have nothing to do other than booking meeting rooms and attending sprint planning, sprint review and retrospective? Of course not, Scrum Master also needs to make sure the team is not distracted by external obstacles, ensure the team follows Scrum processes, help Product Owner to prioritize backlogs, resolve conflicts between team members and the most important is to make sure the team concentrate to work on their stories and complete what they signed up for in that sprint. Scrum Master also needs to make sure the team is self-managing and give suggestions for the team to improve.
Does that mean we need to have a full time Scrum Master? The answer is yes and no. In an organization with many experience in Agile and Scrum process, their Scrum teams probably are already in performing stage and not require a full time Scrum Master – remember Scrum team suppose to be self-managed. In Sage Richmond, most teams are still in the storming or norming stage and may be some teams are getting close to performing stage. Would it be a full time Scrum Master can speed up the teams and quicker to be at performing stage and eventually can be a high performing team? The answer we don’t know, but this is probably something worth to try.
In Sage Richmond we have seven teams and each team has it’s own Scrum Master. Most Scrum Masters spend 50% of their time to do Scrum Master roles and the other 50% either doing implementation or testing. It’s very hard for a team member to do both jobs at the same time and do their very best at both. Especially when we are still new in Agile and Scrum process. Seven Scrum Masters 7×50% = 3.5 people are spending time on implementation or testing. Why don’t we only assign three people from these teams to be full time Scrum Masters and let the other four people to contribute 100% to what they do best? In other words, 4×100%=4 people to do implementation and testing.
However, one thing I want to point out is a full time Scrum Master is an arduous role and demands a distinct personality type to succeed. The best ScrumMasters are real team players, who receive as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team.
People always said that a Scrum Master’s role is similar to the role of a shepherd dog. Do you think we can assign 50% of the shepherd dog’s duty to one of the sheep?
Sprint 10 is our start of IR2 (Internal Release 2), some teams in Richmond start doing UI Porting and some teams are still doing framework stories. Sprint 10 is also an important day that my Chennai 5 weeks trip also has been approved by management. We have three team members in Richmond will be going to Chennai. Our main purpose of this trip is to do as much as we can in order to help the teams in Chennai. Before going, we still have some pre-trip processes need to do. For example, we have to get a letter from both Chennai and Sage offices about the purpose of our trip before we can apply for an India Visa. Once we got the Visas then flight tickets and hotel bookings will follow.
These couple days I have been looking at the team structure for STI teams. They have 4 teams in Chennai, one automation and three development teams. Aside from the automation team which only has 4 team members, all the development teams are consist of 6 Developers, 4 QAs, 1 Developer lead, 1 QA lead and 1 BA which is total of 13 team members. In Agile practice, we should only have at most 10 team members. Too many team members in a Scrum team will degrade performance of the team. You can imagine how much time you have to spend on Sprint planning, daily standup and Retrospective.
With 13 people in a meeting room is tough for all team members. No just because of the meeting room is packed but also too many people join in a discussion is very hard to come to an agreement. I think we need to find a way to streamline this in order to make the team more productive and efficient. This is even a bigger problem for us because we are using a 2 weeks sprint. Everything needs to be efficient and effective within these 2 weeks.