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!


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.

Jelte: I think the whole XLS thing did not work.

Stephen: The advantage is I could put the estimates in and produce the chart. But I think you're right and the task list needs to be on the Wiki.

Stephen: If we can break our tasks down into sufficiently small tasks that a person can do a number of them during the sprint, then we will note the burndown by completed tasks. If the burndown is longer, then we have to ask the estimate for the amount of time remaining, and that is much more inaccurate.

Michal: Small tasks are better if we can make them. But some tasks are hard to split because you need to think about it and implementation goes along with it. If someone takes over in the middle it means a lot of overhead, and there is a dependency. Some tasks are naturally bigger than the small ones.

Stephen: I think what you're saying is that not all tasks will be interchangeable. I think what you're suggesting is that it is more efficient for one person to do all tasks sometimes.

Michal: If we split it into tasks, the splitting would be unnatural. You split the task in the middle, and you don't know the name of the split because there is no "real" way to split it. So you split in half and call one part A and one part B.

Planning for next 2 weeks

Stephen: Not a lot of us are going to be around. I'll be gone on Thursday, then to IETF. Jelte going Saturday. Likun & Ocean will be busy with the IETF. Fujiwara-san also attending? That leaves Michal, Aharen-san as normal time for next 2 weeks.

Stephen: Propose we do reviews and merges. #327 and #356 are main strands... how are we going to merge back together?

Michal: Suggest we do reviews, and then Aharen-san and me can merge these back into #327, then merge #327 into trunk. We won't be stopping anyone from work.

Jelte: That sounds like a good plan.

Stephen: There is also #356. I've done most of the stuff on that, but Ocean wants to start modifying code?

Ocean: Right.

Stephen: Only Ocean and myself working on that, I'm going to be flying Thursday and busy tomorrow, so maybe best for Ocean to continue to work on that branch.

Ocean: Okay.

Stephen: Shane produced a list of outstanding reviews (currently on spreadsheet!), we'll post that to Wiki and send a link around to it. I'll add to that the outstanding tasks on the current sprint, so all of that will go on the Wiki in the next few hours. If people assign themselves to tasks by editing the wiki, we'll track task assignments that way.

Stephen: Then we'll discuss what will form the basis for the sprint after that.

Larissa: Do we need to break down the existing tasks and reviews further?

Stephen: I think they might be okay. We won't have a lot of people around for the next couple of weeks. I am hoping the reviews and merging and other existing staff will be enough to occupy people who will be doing that work until we get to the next sprint planning session.

Jeremy: What about adding new tasks? Are we doing that today?

Stephen: Given the relatively few people who are going to be working, I was not planning on adding new tasks to the sprint. That will come at the planning session in 2 weeks time.

Jeremy: I misunderstood. I thought the one sprint was over, but we are beginning a new sprint now with only a few developers?

Larissa: Yes, but we will re-use tasks from the last sprint since we only have a few people.

Jelte: Yeah I'd like to do a few tasks that came out of the work for the last weeks.

Stephen: What sort of tasks?

Jelte: The work Michal did on the configuration of the recursor identified a few problems with the way configuration is handled and presented by bindctl. Ticket #384 about this. I have identified 3 smaller tasks within that. 1 is a couple hours, 2 are a little bigger.

Stephen: If they are only 2 or 3 hours, then I think we can put those in. I think what you've identified is a way to tie Trac with the task backlog. Regarding Trac as the task backlog is a useful idea. Titles need to be quite good in terms of description so we can cross reference them.

Larissa: In the feature backlog for BIND 9 we've rated things by priority and value, in Trac we have some of that but not all of it. I think if we can assign priority and severity in there, maybe we can figure out some process for working some of them into every sprint. And ones people want can have higher priority. We did that in BIND 9 and possibly that would be useful here.

Stephen: Since we'll put the list of tasks on the wiki if you can e-mail me the ticket numbers you think are important... if they potentially have impact on the A-Team work as well, if they will take a few hours...

Jelte: One is a few hours, the other two are 1 or 2 days...

Stephen: E-mail them!

Jeremy: I benchmarked #327 at the branch point and then also later. It had a 25% slowdown on queries per second. A very significant slowdown. Someone needs to spend some time re-evaluating it and tracking it down. It was in the auth server, but it was abstracted out in #327 in that code. We can either do it now or 6 months or a year from now! Just to point out the auth server dropped from 45k queries/sec to 2k queries/sec. Over time it has been a lot more. It is substantially getting slower and slower.

Jelte: Lot of allocations and freeing in every query right now.

Stephen: To me that is sounding as though we need to tackle this early on. Maybe get some custom allocators and deallocators written. Otherwise we'll have problems later on.

Michal: First solve memory leaks, then optimize allocations.

Jelte: I fixed all the memory leaks I could find.

Michal: I'm not saying speed is not important! But I am skeptical about including it in this sprint.

Jelte: Evan had some ideas about using "new" and pre-allocating data that is done within the event handling system. But that is not simply a one-day task.

Stephen: Does it have an impact on the longer term design? NSAS makes a lot of use of shared pointers. Has anyone done measurements on shared pointers? It could be shared pointers slows things down considerably.

Shane: There is a micro-benchmarking tool in the code base. Ask Jinmei for details.

Stephen: If we need to change the design we should find out early on.

Stephen: Shall we put performance on the sprint in 2 weeks time? There won't be people in the next 2 weeks.

Jeremy: Okay.

Stephen: Everybody happy with that?

[ general grumblings of approval ]

Stephen: Will get the tasks on the wiki today or early tomorrow.

Stephen: When should we start planning for the next sprint then? Maybe we should do the bulk by e-mail for the next sprint?

Jeremy: I think we have to.

Michal: By e-mail meaning dev-list or team-list?

Stephen: I was thinking team list. Doing discussion about project management could mean losing interest of people following the dev list. People are not really interested on work scheduling.

Larissa: Trick is to put technical discussion to dev-list and other stuff to team-list.

Shane: team-list is members only

Michal: Maybe we should make an admin list that is open for reading but not posting.

Shane: We could open the team list for reading only?

Jeremy: It does have some private-only stuff.

Larissa: I think the solution is technical meaty discussion to happen on bind10-dev and then put summaries of sprint reviews to bind10-team.

Jeremy: I think it is disjointed to pick & choose lists going back and forth. Readers are only getting half of the story. I don't think we have very many operation mails to bother readers on the dev list.

Shane: I'll ask the bind10-dev list readers what they think, and hopefully we'll get feedback before we do our e-mail planning next week.

Stephen: I'll put the lists of uncompleted tasks on the wiki.

Stephen: Anything else?

Michal: If I want some code from a branch that is not on the last sprint, is it okay to ask someone to review it?

Stephen: I would say "yes". If you need code from that branch and it needs review, it is okay to ask someone to review it.

Michal: Well... it's not necessarily needed, but there would be less work.

Shane: Makes sense.

Stephen: It should logically be part of the sprint.

Michal: It is a review of ticket #300.

Stephen: Ideally we should do estimates, but with only 2 people I don't think we need to for the coming sprint.

Jeremy: Decisions of not including changelog entries... I've noticed that a few times, and if we have noticeable behavior change, I think it should be noted in the changelog. Some things are said to be minor, but should still be noted.

Shane: Please send mail to the bind10-dev list? Thanks!

Michal: Also it is hard to know what should and should not go into the changelog, so if you could point out what should go in there...

Jeremy: Okay we'll discuss it elsewhere.

Stephen: Thanks you!

Last modified 7 years ago Last modified on Nov 2, 2010, 4:00:41 PM