wiki:RTeamSprintMinutes20101102

Version 1 (modified by shane, 8 years ago) (diff)

--

Attendees:

Stephen
Michal
Likun
Ocean
Jeremy
Aharen
Jelte
Larissa

Stephen: We have come to the end of the sprint. We want to find out how the sprint went. Then we want to plan for the next 2 weeks. There do not to seem a lot of people around for the next 2 weeks. Jelte, Stephen, Likun, Ocean, Fujiwara-san will be at the IETF!

Reviews

Stephen: So far only 2 reviews posted. One from Stephen and one from Michal. So... summaries and then post to list after meeting.

Jelte: Refactoring of IO service to make it more general. Pulled out the DNS serving into another class. Have been working on memory leaks in Trac #327. Was typing to get for review status. (Rest of the week for finalizing writable, which is A-Team stuff.)

Likun: Ticket #318. Working on refactoring test code of recursor.

Ocean: Finished review of ticket #356. Still working on RTT update logic. Seems a little more complicated than I imagined.

Aharen-san: Supporting Kambe and Fujiwara. Working on ticket #347 - statistics in auth module.

Stephen: Summarize and send to list, will be useful. Expanded record will be helpful.

Sprint Retrospective

Stephen: Be brutally honest. How do you think the sprint has gone? This sprint is a bit unusual as this is the first one we have done under scrum rules. Nobody expected things to go right from day 1. Say what you think about planning, execution, whatever. What should we have done, what should we do in the future.

Michal: One problem was the reviews. We did not have time reserved for them. Will result in more complicated merging now because we are working together on the R-Team now.

Jelte: Tasks were not hashed out enough.

Michal: Nobody really knew what to do at the end of the sprint. Should we take a task that will not be finished until the end of the sprint? 1 or 2 days of "dead space" where nobody wants to start anything.

Larissa: The "official" Scrum answer to that is to take a task and break it down into more parts. Take a small part that will only take a day or two, and do your best on that one. That's the approach that is supposed to happen. We have not gotten down the task of breaking down the tasks yet. We need to learn that. It has been bumpy, but in general I am really pleased.

Likun: For me, I can't get the whole picture of all tasks in the sprint. Where is the current sprint now? In the big picture. Sometimes I feel like I get lost in the developing.

Aharen: I agree with Likun. It may be difficult to...

Larissa: I am curious what would help; I'd like to solve the problem but I don't think I understand it well enough.

Likun: Hard to know which task is more important, and what we do now is not so important as other tasks.

Larissa: So trying to understand how current work fits in the big picture, and why we focus on one task at any given time? [yeah] Next sprint will be a bit funky because we have a lot of people at meetings, but for the sprint after that we need to talk about what we are doing and why we are doing it.

Stephen: I certainly agree with the difficulty in splitting down the tasks. We're new to scrum, and with hindsight we were very optimistic to think that in 1.5 hours we could split the tasks and get the estimates done. I think the only reason we got part of the way there for the R-Team is that the work was taking over tasks that Evan and I had started. With the A-Team sprint we had a lot of difficulty in breaking the tasks down. I think we cannot do it in one telephone meeting, and that we need to do it in stages. I think we need to have 2 sprints overlapping: 1 sprint where we do the work, 1 where we are planning for the next sprint.

Larissa: I agree.

Jeremy: Is it normal to overlap?

Stephen: I don't know about that, but I did some reading and it was talking about doing a day's meeting at the start of a sprint. So 4 hours of breaking down the task and then 4 hours of planning poker and estimation. But I don't feel this is feasible by telephone, especially split around the world.

Stephen: So there needs to be some preparation over some weeks.

Jeremy: What I'm concerned is that we can't build upon the completion of one sprint if we're overlapping. I have a feeling we have a lot of components being built, but the developers don't understand what the pieces are. So jumping into the next sprint, we're losing all that information because we don't discuss it after the fact.

Larissa: The review is supposed to entail that. But overlapping might lose that aspect. My take is that we need to have some way of organizing this, and it's not going to be perfect. I don't see any other way to work other than what Stephen is suggesting without slowing our progress.

Stephen: The trick is to keep people working. If we come to the end of a sprint, then we have people sitting around for a day sort of not doing anything. Having multiple strands at one time lets us switch from one to another if need be. I don't agree that doing planning ahead of time precludes coming on from the current sprint. Say we manage to complete 90% of the sprint by the deadline - we may want to continue the 10% in the next sprint. But in the planning meeting, we can focus around the 10% and the tasks we know we want to do for the coming sprint. The problem of discussing what to do next is reduced to a manageable level.

Larissa: I am inclined to agree.

Stephen: Concerning reviews - I think we should include a review task in the task backlog. If we estimate a reasonable amount of effort for the reviews, then we can have all the tasks and all the reviews at the end of the sprint.

Larissa: I quite agree. Because our reviews are a big deal, and a lot of work, and really important, so they should be tasked.

Shane: I think we have to do it that way.

Stephen: How about the actual progress in the sprint. I admit I was a bit intermittent with the updates of the burndown chart.

Michal: Editable list of tasks is more important than a burndown chart. Having a list of tasks that can be edited is more important than that.

Stephen: That is a fair point.

Michal: Better if you can edit it at the time you are taking the task. If someone edits it, then two people can take the same task the same time.