Sprint Planning Meeting: 2011-06-14



Review of past Sprint - organisational

  • At last week's meeting we had to do some reorganisation/creation of the ACL tasks. It would be useful to discuss why this happened and whether it had an impact on the sprint.

Stephen: We reached a bottleneck last week. Resolved this by starting some tasks before the base ACL classes had been completed.

Stephen: Was that okay? Could we have avoided it?

Michal: Could have avoided it if the discussion started sooner than when we wanted to implement it. Have two sprint time for discussing, we would have the whole definition when we started. Discussion took a longer time than we expected.

Jelte: We came to a similar conclusion earlier.

Larissa: Good to keep this in mind. The discussion was useful but was 11th hour, so difficult. If we could get out ahead, then I could have gathered more customer data. Good to anticipate what is coming in the next release when we start a release.

Jinmei: I think the length of the discussion for design of interface was actually expected. In that sense this situation is kind of "as expected". We could avoid that if we started earlier of course. But I don't know if that is always feasible. I think this situation is close to what we could achieve at best. It would be a good idea if we started much earlier than expected release phase.

Stephen: I don't think we should have any excuse, since we have the year 3 plan written down, so we should be able to have the discussion well in advance.

Larissa: I agree. So there are a few things we could get for ACL from customer survey. We need to be looking at one release cycle ahead.

Stephen: We came to the conclusion we need at least 1 or 2 sprints to discuss requirements, then another to discuss design.

Larissa: From a customer perspective, I should be doing that pretty far out front. I'm going to start looking at these things far enough out.

Shane: Are we doing to get distracted by having too many overlapping discussions going on?

Stephen: We might, but otherwise we'll run into the situation where nobody can do any work because we're sorting out requirements.

Larissa: For my work, I would not bring to the team until I have some data gathered up. So it would not be a conversation for the whole 6 weeks.

Michal: Someone will be doing design, and focusing on that, and someone else would be thinking about another thing. So only one person would be focused on one topic.

Jinmei: I think it depends. If we can control it then I think concurrency is better than doing only 1 thing. Probably as Michal said, normally 1 person is more involved in the deeper design of 1 topic. If different people work on different topics while discussing other topics, that is probably the most efficient.

Jelte: I would be more concerned that discussions do not reach conclusion and we don't notice until we try to implement them.

Stephen: I think the way to handle that is to have the person who takes the requirements being the chair of the discussion.

Jeremy: Maybe our end results were not very precise. We have the goal of "implement ACLs". Maybe we could have implemented ACLs without having a configuration. But I did see that Michal had later on created tickets to do the lower level parts... maybe those should have been done first.

Michal: The structure of configuration and the implementation is connected.

Stephen: Have to get the requirements clear. I feel you do need someone who's job it is to oversee it. "A camel is a horse designed by committee." If we're not careful we'll end up with bind10-camel. I suggest if someone takes a requirement or design ticket that they become responsible for it. If there is a discussion then they will be responsible for summarizing the discussion.

Shane: Don't want people to be scared of taking tickets. If this becomes a problem then the rest of the team is here, and the ticket can be transferred if necessary.

Michal: I'm trying to look what is happening with the ACLs, but it is not easy to keep people coordinated. I have some idea of how it would look like if I implemented everything....

Stephen: If you are doing everything yourself you can keep it in your head, but with multiple people it must be written down.

Michal: Yes but you can't write down everything otherwise you would have implemented it. There must be some kind of feedback.

Stephen: BIND 10 development tends to be different from how I have done in the past. In previous environments one person does a feature.

Shane: That's how we used to do it in BIND 10. I like it better like this though.

Stephen: That's fine but it does take more effort in writing things down.

Michal: In short we need to talk to each other.

Stephen: "Design" conveys ideas so that an intelligent person can implement it.

Jinmei: Do we take any actions?

Stephen: When we have another requirements or design task, the person who takes it on is responsible for:

  • tracking the discussion
  • writing a summary
  • closing the ticket

The design needs sufficient detail to convey it to the rest of the team.

Shane: The other takeaway is that we need to look further ahead on our plan for the sprint planning.

Jinmei: Writing down the details depends on the situation. I generally agree that it's better to provide sufficient detail for everyone to implement it. I am also concerned about excessive perfectionism.

Stephen: Design documentation is future maintenance documentation. There are an awful lot of files, so if in 2 or 3 years we get someone to maintain BIND 10, at least design documentation will give a reasonable idea of how things hold together.

  • Other comments

Review of past Sprint - technical

The goals of the sprint were:

  • Finish Logging
  • Implement ACLs
  • Logging

Michal: Python API is in review. Missing a way to pull configuration out of configuration manager. But should be possible to start updating programs without this.

Stephen: C++ API is complete, need a way of pulling configuration into it.

Jelte: That is merged. That created 3 new tickets, 1003 to 1005. I am reviewing the Python API. No fundamental problems, minor things, nearly done.

Stephen: Have we added new logging statements to all the modules?

Jelte: Still quite a bit of work to be done, but it is easier work. Still a few hours there!

Shane: Do we still have work on the C++ side?

Michal: Mostly complete.

Michal: Someone should go through and check the programs, before we declare it complete.

Jeremy: Task to install documentation for the logging for the end user?

Stephen: We could do that. I've been playing around with a program which goes through all the message files and creates an HTML page with message codes and descriptions.

Michal: I think more important would be documentation of how to configure the logging.

Stephen: Yes, that is dependent on the logging configuration tasks.

Michal: I expect the Python will look like the C++, which is complete.

  • ACLs

Michal: Base class is merged. ACL class is being reviewed. I just started the loader which pulls the configuration into the class. It turns out we will need something, because all of this is templated and too generic. So we will need a header with typedefs or something that names the correct classes and creates the classes.

Stephen: Do we have something documenting how we configure ACLs?

Michal: No because we don't configure ACLs yet. Some kind of documentation will come up from the class I am writing now - the loader. If not documentation, at least some examples.

Stephen: Looking at the list of ACL tasks, are we missing anything.

Jinmei: It depends on the feature-level goal. Our goal is to add ACL only to the resolver? Or we want to do it for some other application too? Are we okay with emmitting simple ones like allowed IP address or whether we want more complicated one.

Michal: We have tasks for that, just not sure if we are going to implement them in this sprint or in future one.

Michal: Maybe some of the tickets I created may not be relevant any more. For instance #982.

Stephen: Please add a comment that whoever takes that should look at what has been done to assess whether it is needed.

Sprint Planning

  • Goals for the current sprint

Need to add tasks 758 to 764 (all the tasks for adding logging to Python programs).

1003, 1004, 1005

1008 (bug fix)

+new task for configuration of Python logging API

+document message codes

+document how to configure logging

Shane: ACLs on transfer code is probably most important.

Jinmei: point is to provide user visible feature.

Shane: requirements work for new model for writing the data sources.

  • What tasks do we carry forwards?

Unfinished tasks in the current

sprint can be found at

  • What tasks do we remove?
  • What tasks do we add?

A number of potential tasks can be found on the milestone


Jinmei: Most tickets listed by me. Did others forget to list them in the next?

Michal: I would like to build & test with STL debug mode. I don't know if there are tickets for that...

Jelte: I see 2 from me. I miss the logging related tickets.

Stephen: Tickets in the general backlog?

Stephen: We want 6 bugs or so?

(05:28:41 PM) vorner: should we have a 6-week period reserved for the whole list?

Stephen: Maybe first sprint for the following release we dedicate to fixing bugs and handling design and requirement issues.

Shane: Maybe something for next BIND 10 call rather than the sprint planning session.

Stephen: Can we ask Jeremy to come up with a half a dozen?

Jeremy: Okay. (Will email Stephen.)

Jinmei: I suggest #1001 - it affects actual deployment.

Jinmei: Also suggest #710.

Any Other Business

Jeremy: Propose I do the release on Wednesday, July 6. I create a branch on the 29th of June.

Jinmei: So does that mean we are changing the release cycle from 6 weeks to 7 weeks?

Stephen: Only for this release. We release 1 week after the final sprint of the release cycle. Personally I think this is a very good idea.

Jinmei: I'd like to be sure about the plan for the bugfix. Are we going to include 6 bugfix tickets?

Stephen: That's the idea. #710, #1001, and 4 others that Jeremy will choose.

Jinmei: What's our focus for the next/next release?

Michal: Ticket 1009 is splitting the refactor work into tasks. + Ticket 1009 will be included in the forthcoming sprint

Stephen: We may need to add a design task to the sprint; we can decide this next week.

Shane: Year 3 plan needs to be updated based on what actually goes in next release, and dates adjusted 1 week as per release plan.

Stephen: Maybe take it up offline between Jinmei and Shane.

Last modified 7 years ago Last modified on Jun 14, 2011, 3:58:43 PM