1

If I split up the development into a timebox with 3 phases: planning (e.g. with planning meeting), functional progress (software development / implementing user stories) and finalization (e.g. with review meeting). What is the iteration/sprint? Does the iteration also contain planning and finalization or are these parts of a progress "outside" of the iteration/sprint? If I want to create a burndown chart and start while I'm within the planning phase (adding user stories and estimations) then the burndown is somewhat useless... because you never will meet the ideal line (because you start some days late with the kickoff after backlog grooming and planning meeting.

How do you solve that problem?

Do you plan Iterations as timeboxes that follow immediatly (containing planning and finalization) or is planning and finalization outside of this timebox?

What I don't like in the mind set of "iteration is everything" is the aspect of planning the thing what is already started and where I'm already in and changing things where it is said it should be stable (for the iteration). The iteration backlog should not be changed during the iteration/sprint!? How can this be done if the planning is inside and I need to add user stories and estimate them with the team. From my perspective the iteration backlog for the team is fixed (should not be steered to other direction) within the sprint from the time point starting the functional progress/work of implementing the user stories (with rare exceptions, for example could get new story from backlog). Which means you are "agile" and can react within the max of a timebox of 1 week. I don't think that "agile" means do immediately put the hammer away and change your iteration goal without having good reasons.

What are arguments for/against?

Improve this question
2
  • From my perspective the iteration backlog for the team is fixed That is part of the problem. It's not fixed, and even the Scrum guide acknowledges this: As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Ideally, changes to the Sprint backlog should be minimized, but they aren't prohibited. It seems like you're trying to use many traditional, plan-driven techniques in an agile environment. That's not going to work.
    – Thomas Owens ♦
    Commented Mar 3, 2017 at 19:46
  • You are correct. Indeed in reality the iteration backlog gets new User Stories from the product backlog, that happens some times in the projects (for example if finished all iteration backlog stories... why wait?). What I meant correctly is that the iteration/sprint should not be disturbed. And this means to give the team time to finish a User Story. If you change the priority all the time (moving the project into different directions in the middle of an iteration) you are going to have unfinished work that needs to be rescheduled.
    – Beachwalker
    Commented Mar 3, 2017 at 20:36

3 Answers 3

Reset to default
5

The Sprint is the container for all the work that is done in the sprint, this includes Planning, Sprint Review and Retrospective and all the work in between.

Nothing prevents you from adjusting the Burndown to start on day 2 and target teh day before the sprint review.

The Spritn Burndown is never meant to be followed along the ideal line. The ideal line helps the team assess whether they're ahead or behind their current plan so they can take action and adjust the plan.

Software development tends to be complex and can be muddy, honest teams will rarely follow the ideal line. They find new work along the way, find alternatives that may be better, receive feedback or find new corner cases that were previously unplanned. When the burndown reflects these changes continuously, the team can use it to make informed decisions.

PS: Grooming has been renamed to Refinement. The reason behind this has to do with negative connotation associated with the word Grooming. Something to do with young kids and nasty older men (generally) and webcams.

Improve this answer
2
  • Thank you for the info about the renaming to Refinement. I'm not a native speaker and didn't knew that possible negative association.
    – Beachwalker
    Commented Mar 3, 2017 at 18:34
  • The point about moving the begining and end points of the burn down is important. At my current company we do 3 week sprints, 15 days. The first day of the sprint is planning day, the last day is review and retro. Those two things don't usually take all day but we treat them as such so for planning purposes we plan 13 days of work. We also do not expect any work to be done on planning day after planning, the clock starts the day after. And we expect all work to be done at the end of the day before review/retro. Any free time during those two days is seen as bonus innovation time.
    – Hangman4358
    Commented Nov 21, 2017 at 14:31
5

In Scrum, as defined by the Scrum Guide, the Sprint includes "Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective". So the answer to your question from Scrum's perspective is yes, planning your iteration (and also reviewing your iteration) are part of the iteration itself.

However, Scrum is not the only way to be agile. Just because Scrum says something does not make it so. You can choose to base your Sprints on time excluding your planning and retrospective activities.

However, I think your concerns about never meeting the ideal aren't that big of a concern. The ideal line is just that - ideal. It assumes constant, steady work. It's an indicator on how you are doing with completing your story points against your iteration timebox. You'll probably never follow your ideal line exactly, but you can use it to raise early warnings to stakeholders if achieving your commitments are at risk.

What I don't like in the mind set of "iteration is everything" is the aspect of planning the thing what is already started and where I'm already in and changing things where it is said it should be stable (for the iteration). The iteration backlog should not be changed during the iteration/sprint!? How can this be done if the planning is inside and I need to add user stories and estimate them with the team. From my perspective the iteration backlog for the team is fixed from the time point starting the functional progress/work of implementing the user stories.

It seems like you are trying to apply traditional, plan-driven techniques to agile methods. That's not going to work.

First of all, iterations are not guaranteed to be stable. Ideally, they should be mostly stable. If you're running by-the-book Scrum per the Scrum Guide, it even acknowledges the fact that the Development Team can change the Sprint Backlog.

Second, Sprint Planning is not a detailed plan. It only addresses two issues - what the team can deliver in the Sprint and what work will need to be done to deliver. The Product Owner generally has an objective in mind to achieve and works with the Development Team to order the Product Backlog based on that objective and any technical considerations. The Development Team and Product Owner continuously collaborate on defining the requirements and tasks that are needed to implement those requirements.

If you're used to more fixed work, more calculated responses, agile is going to be challenging. The agile methods are meant to be responsive and data-driven, but also collaborative. You aren't going to have firm plans and actions set up-front - a lot of it comes from experience and what everyone feels is the right thing to do.

Improve this answer
10
  • Yes, but if the ideal time is drawn in a chart it is a thing you should try to reach... otherwise it is useless. Also if you never can reach it (because the calculation starts before the kickoff has been done) it might be demotivating people (and makes them think why we look at useless lines in the graphic). This makes me skip this every time when I'm doing the review and focus on the User Stories we have finished (or not). Even during the Iteration counting the User Stories (and points) helps more than this chart with the tool we are using (maybe wrong tool!?). We use Polarion.
    – Beachwalker
    Commented Mar 3, 2017 at 18:12
  • 2
    @Beachwalker You should not be trying to reach the ideal burndown. It's a guideline. If you are below the ideal burndown (you are completing far more work far faster than expected), it's a signal that your team should begin the work to refine more backlog items for the sprint. If you are above the ideal burndown, the team should try to figure out why and let the stakeholders know they are likely to not finish all items in the sprint. It's value is in the middle of the sprint, to give stakeholders a quick glance on status per plan and raise concerns easily.
    – Thomas Owens ♦
    Commented Mar 3, 2017 at 18:25
  • But when you say you should not try to reach the ideal burndown but also say there are things to do if you don't reach it (because it is a signal, e.g. for wrong planning etc.) then this contradicts your first point. Then it is an important line to keep an eye on and take your findings for the next iteration/sprint.
    – Beachwalker
    Commented Mar 3, 2017 at 18:31
  • 2
    @Beachwalker My answer addresses that. If you were doing Scrum-by-the-book, your Sprint begins at the start of planning and ends after review and retro. You don't have backlog refinement stories on your board - planning, refinement, review, retro, and daily standups are part of the Scrum process. If in planning, you bring in 30 points into your 2 week sprint, your ideal line starts on the date of planning at a y-axis value of 30 and ends at a y-axis value of 0 2 weeks later. But it's also OK to have tasks without user stories - that's not an issue, either. But tasks should be value-add work.
    – Thomas Owens ♦
    Commented Mar 3, 2017 at 19:30
  • 2
    @Beachwalker: The burndown should be product oriented. You can include tasks without a story, as long as they add value to the product. The scrum ceremonies (planning, refinement, etc) don't add value to the product, so they are not included in the burndown. The ceremonies do take time, so they effectively reduce the amount of work that the team is capable of taking into a sprint.
    – Bart van Ingen Schenau
    Commented Mar 4, 2017 at 9:17
3

Planning is part of the sprint.

It seems like you are looking at a sprint as if it was a block of time set aside for programming and testing. That is not what a sprint is. A sprint is a block of time set aside for a team of people to work together on a problem. Part of that work is coding, but part of that work is planning, part is the demo and retrospective, part of that is going home and sleeping.

As for the burndown... it's important to remember that the ideal line of a burndown chart is an indicator rather than a goal, so the fact that you may never reach it isn't a problem, unless at the end of the sprint you still have work to do.

It's sole purpose is to help you see if you're likely to finish on time or not. That information is pretty much useless the first day or two of the sprint because you haven't done much work, so it doesn't much matter how the planning affects the chart. It's (arguably) completely useless the last couple of days of the sprint too, since by then you should already know if you're going to get finished or not.

So, the burndown chart is really only useful for the middle part of the sprint. If that is troublesome, you can certain draw a burndown chart that starts after the planning and before the demo and retrospectives, but you're making the process more complex than it needs to be.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.