wiki:WeeklyMinutes20101026

Roll Call

Shane
Stephen
Jelte
Michal
Likun
Jerry
Ocean
Shawn
Larissa
Kambe-san
Jinmei
Jeremy
Aharen-san
Hankins
Fujiwara-san

Credits in ChangeLog

Shane: Purpose for change log? People who download the software and want to know what is new?

Jeremy: The administrators.

Michal: Too long for them?

Shane: It depends. I like the MythTV version, which will have a short summary, and then a list of complete changes.

Jeremy: I've been trying to do that with our releases. Summarizing in the release announcement.

Shane: I would think that people submitting changes would like to have their names in the change log.

Michal: If a change causes bugs, or other problems, they know who to ask about the change.

Stephen: If people at ISC don't know the reasons then it should not be incorporated in the release.

Michal: The person who wrote it has the best information about the code.

Stephen: That supposes the person is still around and has not moved on to something else. With a release, the important things are what bugs have been fixed and what new features are present. Things like "refactoring code" are not important. Jeremy, you produce that information in a release, right? From a change log you make a summary of the change log when we do a release.

Jeremy: Yes, we don't want to write a summary, so we're hoping our existing change log is enough for the administrators. The full details for developers are in the code repository.

Michal: In that case we write too much in the changelog. There are 50, 60 changes per release.

Jinmei: In my vague memory, the original plan is to mark important changes with the "operational change mark", which is an asterisk. So administrators can only refer to those changes. It probably doesn't work very well as expected. I guess we need changes.

Shane: I think that since we only have an hour, we should take this as our message from today:

The ChangeLog needs work.

I think it is close to what we want, but clearly not perfect.

AP: Jeremy will write proposal and send to list, mostly based on Jinmei's feedback.

Jabber vs. voice

In general

We have had this discussion before. But our meetings are a bit changed.


Stand-up calls

Shane: Today we do a voice call, then follow up with a post to the bind10-daily-status. What do people think about that?

Jinmei: I was not aware we had both the jabber and the voice call. It seems to be redundant. In general, if we have a text message we don't need to have the voice. That's my basic question. There is not expected to be any discussion about reporting things, if I understand it correctly. Considering all of this, I don't understand why we need voice in the first place. I understand some part of it may be nice in voice call - like follow-up discussion, or if you want to raise a concern about the daily status maybe that is better done in voice. But for a simple report thing why can't we just use the chat room?

Stephen: My point of view is that there are 2 things. First I find it useful to listen to what people are saying. I can quickly come in and ask them things. What goes in the jabber room is a summary of what people have said. The second thing is purely a social point of view. It's nice to dial in at 10:00 and have a bit of a chit-chat.

Larissa: I agree with you Stephen, and part of the idea is to have more team work.

Shane: Also, without the daily call people skip their reports.

Jelte: I like the forcing function of it.

Michal: I also listen to what other people saying. If what you are doing is writing into the jabber room nobody forces you to read what people are writing. But if you are on the call you listen, so you have a better idea of what people do.

Jinmei: Forcing people to listen to something requires people to understand in the first place. One of the source of my question is that the assumption is different sometimes. I understand the importance of social activity, and the intent of communication if you use voice, but that is true only if you can understand that.

Shane: We haven't heard from anyone from CNNIC or JPRS.

Jinmei: Maybe it's only me, in which case I am fine with the current style.

Michal: Maybe they don't speak about it because they don't know what we are talking about.

Jinmei: About the talking part, I don't think it's a problem in this case. Because it is very fixed format, and you are supposed to report very simple things, and not discuss details or complicated technical things for example. And if we don't have an optional jabber room, I wonder why we make a duplicate.

Shane: It is useful for people who are not on the call.

Jinmei: Yes but that can also be a replacement of the voice part.

Likun: My opinion is the same as Jelte.


Sprint planning

Shane: We have just started this, so we don't have much experience. It is something I do not want to talk about now, but do want to come back to in a few weeks.

Scrum after 1 week

Shane: Impressions?

Stephen: You're talking about the scrum rather than the sprint planning, but they run in to each other. In the R-team we isolated tasks, and they were following on tasks that Evan and I had been doing. So we had some idea of the complexity of the tasks, so we put down as days of work.

The A-Team task list was a more awkward thing to come up with. We took the stories and had a go at pulling them down into tasks, but some tasks were at too high level. Jinmei broke them down, and we did an estimating session today. One of the difficulties is that we have a telephone meeting. You don't have the feedback you do in a face-to-face meeting. We need to have a look at the stories - some are so high level. They need to be decomposed into small stories, tasks to complete those stories. Second thing is that even though Scrum talks about estimating for tasks. I don't think that works. I think we need to split into tasks, people go away and do homework, then when we come to planning session with a good idea about what is involved in the task. The planning poker is taking quite a long time, something like 10 minutes per task by the time we've explained the task, voted, had a look at the result, explanation, revote. That's an awful long time to do estimating. That means for every task you are spending an hour work time estimating.

I think we need to go away and break the stories into much smaller tasks before we put them to the team. Then the team can discuss it. Then there needs to be a gap where the team goes away and thinks about the estimates. That way we can get through the planning poker much faster.

Stephen: In terms of the estimating side, I've started off trying to do this burndown on a sprint just to start getting some numbers out and seeing what we come up with. Various other projects like to do a burndown as the result of the sprint. They estimate the size of the stories and then each sprint is concerned with breaking the sprint up into tasks and then they work out how many points of the story they've completed in that sprint. In this one I wanted to try to doing a burndown on a simpler basis so we could try it out and see what it is like. With hindsight that might not be the best solution. The problem comes estimating the time remaining on a task. It's a fairly true statement that software task gets 90% done in the first few days and remains 90% done for the next few weeks. So we should only measure completed tasks, which will give us a jagged burndown. This is to get meaningful figures out of the burndown (which is just a way to chart progress). They must be 2 or 3 days per task so we have a reasonable number of tasks completed in a 2 week sprint.

That feeds back to task planning, so if we have a task that is complex, maybe we haven't broken that task down far enough.

Jelte: I agree with you on trying to get smaller tasks, but I don't think going away to look at tasks and then coming together helps. I think it will take more time. I don't think it will make planning poker shorter, and it will use up time looking at stuff that they would not have to if we did not have that.

One problem is that planning poker is *supposed* to take long, and 10 minutes per task is not really that long.

Michal: I like when I don't know what to do, I have a short list of tasks I can choose from. This is a major advantage for me, because with Trac I would go through 100 tasks and decide what to do and what not to do and so on. Nothing really bad happens if we estimate wrong, so maybe we just make estimates which are probably wrong but we have some idea.

Jelte: I blah blah garble garble... we haven't gotten much experience with designing suitable tasks yet. For example in the R-Team we had "refactor into DNS library" which I thought was simple but was estimated at 5 days. Just an example that we might just need to get better at defining tasks.

Larissa: I think that if the feature items were more complete that might help.

Michal: We're spending too much time on estimating and we might lose time for work. Estimating is to do the work better. So I think we are taking this too seriously. So if we care less about the estimates that the mistakes will be hidden in the statistics. So we should maybe care a bit less about how we estimate and how we organize the work... if we do more organizing we do less working.

Jelte: In general that's true, we have been talking about Scrum but not the actual tasks. If they are not well defined you can start and not know what you are doing.

Stephen: I agree with Jelte there. Everyone initially accepted the tasks and then starting asking "what does it actually mean?" We should define the tasks such that it is unambiguous as to what we are doing. Regarding estimating, but when Shane talks to the BIND 10 steering committee he will be happier if he knows what he can promise them.

Larissa: Yes it is important for that.

Stephen: Estimating is difficult, so one of the things the scrum method tries to do is avoid an estimate in days. What it is saying is you are more accurate in saying "this task is twice as long as the other task".

Michal: You mean estimates of time are not important, but that we understand what the task is. If people estimate differently we do not understand the task?

Stephen: No, people do estimate differently, but people can say "this is 2x as big as that" and they are more accurate than if they estimate an actual date. Also these estimates of relative sizes should get more accurate as we proceed. The burndown chart is to figure out how many "points" the team will go through in a given time.

Larissa: Over a series of sprints you should be able to estimate. I also wanted to say that I was reassured that everybody has trouble with estimation in the beginning and this is normal.

Jelte: I think the estimate discussion gives us the benefit that we *do* think about the tasks.

Larissa: Also one other thing I heard about scrum, is that we will see all the hidden tasks and details lurking around.

Jinmei: We've spent almost a week without making any development progress. But if we work as a team we need a clearer definition of a task. Otherwise only someone who is very familiar with the concepts can work on it. My understanding is that we need to accept this overhead. How we can improve the efficiency of the planning stage. If we use one week every time we start a new sprint it doesn't make sense. I guess we can only see how we reduce that over several times and hopefully we can improve that.

For example if we can complete it in a day and we have work for the rest of the period, then we are okay. If we need several days even after we have done this several times then maybe we should do something.

Stephen: We have to adjourn for a day due to time differences. Thinking about the sprint planning we've done so far, it was Evan & me that came up with the task list, or Jinmei. Maybe we should short-circuit, by taking stories and giving those to someone. Then in the next meeting we can talk through the tasks and make sure they are well-enough defined, and then maybe do the estimate in a 3rd meeting. Or Jelte you think this is an intrinsic part of the task discussion?

The main thing is break down into initial tasks. It gives us something to base the discussion on.

(In)Sufficient developers for the A-Team

Shane: Concern is not enough developers on the A-Team?

Jinmei: All of C++ coders for BIND 10 moved to the R-Team. We just today noticed that the A-Team is actually smaller than originally thought.

Larissa: Scrum should have between 5 and 9, +/- 2.

Shane: We may need another person to make that number.

Jinmei: We originally thought Tingting would have time for A-Team development, but that is not true.

Jinmei: Also some of the developers are not expected to use their full time for the development. I don't know if the original plan of team organization, but was it included in the team planning? The percentage?

Shane: Yes that was included.

git migration status

Shane: I think the discussion on the list is basically done.

Jeremy: Is there any timeline for that?

Shane: No, I wanted to discuss this with you. :)

Definition of "done"

Larissa: I can send a mail to the list about this?

AP: Larissa will send mail to list about definition of done.

Last modified 7 years ago Last modified on Oct 26, 2010, 4:06:16 PM