Title: Initial Sprint - Kickoff Observations Date: 2013-07-09 Tags: agile, scrum, observations Published: false
Here are the large topics covered, in order, with my thoughts as appropriate.
This was the first thing that the team picked. The teammates were asked to think of names before coming to the kickoff. This probably should have been after team introductions.
Each person was basically put on the spot to list at least one team value. It became more of a lot of people pitching out ideas. In the end, a team of about 10 people cam up with 10 items. One thing I would like to see is at the end of the planning meeting, come back to this list and narrow it down to three to keep in mind. This may be coming.
Vacation planning / team strength
I would not stress over people out for one day; instead, pick a threshold. The reason why is because it gives a false sense of accuracy if you’re precise to one day. To me, the goal is to think in large percentages in precisions of 10, and that should guide your threshold. If one person is out one day, you do have to consider what that does to them plus the person they are paired with. But even still, in a 2-week sprint with only 4 teammates (“pigs”, or ones responsible for doing the coding and testing work) you have really only impacted the team by 5% (2 pairs at 10 business days each - 1 business day for one pair = 19 business days / 20 = 95%. You could possibly make the argument that it should be 10%, but I don’t buy it and I say let the velocity calculations handle the individual days of vacation.
That’s not to say you shouldn’t know who has these individual days of vacation, because you could run into the situation where lots of people have days scattered throughout the sprint, and in that case, you cannot simply say we lost 5 business days out of 20.
In summary, it’s somewhat of a gut feeling, don’t stress over one day, but do pick a threshold that you feel will impact your team.
Use spreadsheets for now; tracking time per item? WHY?!?!?!
Probably should have started here, but they did hit it. Good catch by Karen.
Team objective / project outline
This was described next, detailing where they are and where they are going.
Story discussion / views
This team is split between two locations. The team set up a desktop share and a conference line, but it is always difficult to remember that there are people on the phone. You have to try to focus on pausing to make sure the people on the phone are keeping up and address any questions they may have.
Also, this started out with explaining the difference between Stage 1, which is what is currently implemented, and Stage 2, as well as the branching that needs to happen with it.
They said T-shirt size but then applied Fibonacci numbers to these sizes. I’m conflicted on this. I discussed it with Manny of Agile42, and his point was that people new to Agile are hung up on hours, so the Fibonacci is a way to let people map that sizing in their mind as they transition, but that they should not be using Fibonacci six months from now. I admit that is something I overlooked, the new/ramp-up to the system, but that said, I have always felt the Fibonacci sequence was wrong for many reasons.
First and foremost is because it makes people think about the number sequence, and makes them focus on the differences between them, rather than the actual story.
Second, it supports the false idea that an Extra (at 13) is equal to a Medium (at 5) and a Large (at 8) and that is not the case at all. It’s back to false precision for me again.
My preference is 1-3. You have to teach that the difference between the points does not scale anyway. To me, the sequence of 1,2,3 is extremely easy and also is very obviously sequential. That is at odds with the statement that they don’t scale, but to me that helps reinforce it.
The best argument I have heard against 1-3 is that there is not enough of a spread between the Large and the Small, so it could lead to inaccurate calculations of velocity. The problem is, this just isn’t true, and in fact, the larger gaps magnify it!
Let’s assume that on a given sprint, a team estimates the stories both ways and tracks velocity both ways. They complete one large, two mediums, and six smalls, for a total of 9 stories. In the 1-3 numbering, they completed 13 points; in 2-5-8 it’s 30, or in 3-5-8 they have completed 36 points. Then lets assume the backlog is full of large stories, more than we can possibly take. In the 1-3 numbering, they’ll have 4 stories. In 2-5-8 it becomes 3, and in 3-5-8 it’s 4. Now flip that and say that they’re all small stories in the backlog. 1-3 is then 13 stories at 1 point each, 2-5-8 is 15 at 1 point each, and 3-5-8 is 12. Those are all relatively close.
The point is that the scale doesn’t matter!!! So if it doesn’t matter, why not keep it simple? Make it 1-2-3, and tell people that the numbers do not matter and do not indicate size, a small + a medium does not = large.
Discussing the stories
Be careful not to rush it; spend enough time but not too much.
While this meeting is not about getting all of the definition out about a story, it is about making sure there is enough information present to get you asking the right questions. This is difficult and there is a balance that comes from practice.
Try not to think about stories at the individual level. We all succeed or we all fail as a team. Use everything you have at your disposal; some stories may make sense to have one person work on them, but generally you should pair because you get constant peer review and people double-checking their work. Keep in mind that the pair can take a story and DO NOT have to break it down into individual tasks that each person can work on independently; that’s typically just setting you up for failure.
This caused a question about whether there is a need to track individual contributions to be raised. My answer is only if this is defined by the business, reminding we succeed or fail as a team. The team members mentioned it goes back to the team values, and asked / volunteered it is really up to the team to handle this. That is exactly what we want to see!