Loading ...
Sorry, an error occurred while loading the content.

Re: sharing experience in sprint planning

Expand Messages
  • Petri Heiramo
    Hi again, ... I still don t like the feeling of PO putting pressure on the team , since that does create an external influence on the team. The pressure to
    Message 1 of 4 , Jun 25, 2009
    • 0 Attachment
      Hi again,

      > > > At the same time, I feel the PO is more capable of pressuring the team
      > > > because of this ordering.
      > >
      > > Is this particularly desirable?
      > No, it is not, that's exactly my point and why I wanted to hear from
      > others. I feel that at one hand, doing the budget makes the meeting
      > run smoother and people more focused on the next Sprint, and on the
      > other, the PO get a number he can put pressure on.

      I still don't like the feeling of "PO putting pressure on the team", since that does create an external influence on the team. The "pressure" to do as much as they can for the PO should come from within the team (with given agreed quality level). I personally feel this internal pressure is better exemplified by the team considering if they can take more work or not, and not by the PO asking for more one way or another.

      The budget also serves to enforce "an expected amount of work completed", especially if the team doesn't feel confident about the amount of work they feel they can take.

      If you have a problem with this "pressure", it might be an issue you can discuss in a retrospective and seek together a balanced way to achieve the result.

      > > > The PO tries to get the team to commit to as much
      > > > as possible, and a lot of communication is done around the estimates of the
      > > > each individual item.
      > >
      > > I don't personally feel it should go like this. I think the team should want to commit to as much as they can, but to no more. Many PO's would gladly see the team take as much as possible, but I've seen PO's who prefer quality over quantity, and they are sometimes concerned whether the team is taking too much.
      > >
      > > > Has anyone here experienced doing the estimating to the ProductBacklog first
      > > > and then deciding on the number of points available ?
      > >
      > > Like I said, I don't do a budget and I think it's not a good idea.
      > Question, if you don't do budget, how do you get to a decision to
      > substitute a big item with a set of small ones ?
      > In my case, with the budget, It becomes just a matter of doing
      > Knapsack algorithm to facilitate the decision.

      First of all, we usually have an idea (or actual measurements after the first few iterations) of the team's average capacity, so that already clearly indicates which stories are clearly too large. Also, the team and PO can usually agree which ones are "too large", for a reason or another. Third, I coach the team and PO to try to split the stories to a level where they can take at least 3 to 5 stories to an iteration (except maybe in the very first ones), so that guideline also helps for them in getting the stories to a right size.

      Some of those are equivalent to a "budget", but without the explicit tool. For example, the team and PO are aware of the velocity, and we do often compare the commitment against the average just for the sake of a sanity check, but I always prefer to do it after the planning. During the planning I always try to use the "if you do all these others, can you commit to doing this one, too?" line.

      > > I prefer to do the estimates already before the sprint planning, during the previous iteration, so that the planning time isn't spent on estimation itself. There are obviously some late moment changes, because I ask the PO first if the PBL is up-to-date and some things can easily pop up at that moment. Or the PO and team decide to split some stories during the meeting, so they have to re-estimate the pieces.
      > What do you do in the first Planning ? I also see that from the second
      > Sprint On estimating becomes a lot easier.

      In the first iteration planning we have the backlog from pre-game, which at that point should be up-to-date with priorities planned during it. The very first iteration planning typically revolves around the very core functionality, and often not much of it, because it often seems that teams may have to spend up to 50% of their first iteration in setting up all the environments they need in development (this work obviously starts in pre-game, but we usually don't want to extend that too long and just get going). Often the core functionality also requires significant investments into architecture which takes time.

      Yours Sincerely, Petri

      Petri Heiramo
      Process Development Manager, Agile Coach (CST)
      Digia Plc., Finland
    Your message has been successfully submitted and would be delivered to recipients shortly.