2

Sitrep: I have finished a story that I could not complete within iteration while it was planned to be completed. It's necessary to get this done and ASAP since it's a prerequisite for other stories and tasks, so I have just finished it several days later after iteration ended.

Formally, the story should be thrown into backlog and revisited, but why really? There would be no point to it given the practicalities: it had to be completed anyway, reviewing it again would bring no new insights, etc.

So the question is are there any practical benefits to using iterations as such and not just measuring velocity using story points?

4 Answers 4

2

TL; DR

Iterative time-boxing and estimation are the very foundations of Scrum. You can't "do Scrum" without incorporating these baseline concepts.

Prelude: Assessing Your Practices

Before addressing your question, it's necessary to examine your practices to see if they are really Scrum. We'll take them one by one.

  1. I could not complete [a story] within iteration while it was planned to be completed.

    This is Scrum.

    Even when one follows the Scrum framework and implements its best practices, not every sprint will be a unqualified success. However, if you routinely handle work that can't be completed within the defined time-box, the Scrum Team is free to resize the time-boxes (e.g. increase sprint length) or reduce the number of story points they commit to each sprint.

  2. I have just finished [the story] several days later after iteration ended.

    This is not Scrum.

    In theory, if your sprint just ended, you should be performing post-sprint activities like the Sprint Review or Sprint Retrospective, or have already moved into the next Sprint Planning cycle. In practice, maybe you did the work over the weekend after the Sprint Review but before the Sprint Planning session.

    While that shows personal initiative, it violates the principle of keeping the costs of all work visible to the organization---it looks like "free" work from a project management perspective---and therefore contravenes the intent of the framework.

  3. [T]he story should be thrown into backlog and revisited, but...it had to be completed anyway, reviewing it again would bring no new insights, etc.

    This is not Scrum.

    First of all, deciding what stories are still relevant to the project is the job of the Product Owner. Perhaps the company wants to shift priorities or reallocate resources, or maybe new information has come to light forcing a strategic shift in the project. By not providing the Product Owner the opportunity to re-prioritize the story, you undercut the organizational flexibility the framework is supposed to provide.

    Secondly, Scrum is based on principles such as time-boxing, estimation, and inspect-and-adapt. If you ignore time-boxes, do not perform estimations, or do not inspect process failures and adapt to changes in your requirements then you aren't doing Scrum.

    Thirdly, the Scrum framework requires that work be accounted for in order to product useful scheduling estimates. Either your work was done outside the boundaries of a sprint, or it was done in another sprint without consideration for the team capacity for that sprint. In both cases, this "invisible work" harms the framework and skews the metrics, making the scheduling process less reliable for rest of the team and the overall project.

In general, it appears that you aren't following the framework's guidelines. As a result, you and your team may not see the expected benefits of the framework, and will naturally question the usefulness of various Scrum practices and artifacts which don't appear to be adding value.

Your Core Question

[A]re there any practical benefits to using iterations as such and not just measuring velocity using story points?

You can't measure velocity without time-boxing your work into iterations. Even if you look at other historical measures of productivity, you will need to impose some form of periodicity to your calculations in order to derive a meaningful result.

In addition, velocity is a key metric for predicting team capacity for a given time-box. "Velocity" without time-boxing is often a synonym for management target; targets are goals, rather than useful measures of historical performance or future capacity.

Finally, if you discard iterations as a planning tool, you lose the ability to plan or schedule work in a meaningful way. While other frameworks like Kanban rely on average cycle times rather than time-boxed sprints for planning and tracking, all agile methodologies require iterations of some type to drive them.

5
  • great answer! If you ignore time-boxes, do not perform estimations, or do not inspect process failures and adapt to changes in your requirements then you aren't doing Scrum." - well, apparently we don't, given on how I match your guidelines against practice of my project. TB accounted for. Feb 6, 2013 at 17:53
  • However, I still have some beef with your explanation: "Even if you look at other historical measures of productivity, you will need to impose some form of periodicity to your calculations in order to derive a meaningful result." - why? can't we just measure cycle time (incidentally it is precisely idea of cycle time in kanban I knew beforehand that made me realize that perhaps timeboxed iterations are superfluous). While "velocity without timeboxes" can indeed be "political, apriori mgmt target", so can anything else. Feb 6, 2013 at 17:54
  • What I'm slowly getting at is that while iterations are useful indeed as periodic evaluation, backlog reorganization by Product Owner and so on, velocity indeed could be measured as number of story points divided by cycle time: why should this not be meaningful measure of velocity? This would be like saying that you can only sample car speed every half an hour. If you have n stories between day A and B, sum up their points and divide it by number of working days between A and B. It does not seem relevant to me if A and B happen to hit precisely iteration start/end days. Feb 6, 2013 at 17:58
  • I'm testing hypothesis here: e.g. that you could discard iterations, revisit backlog by Product Owner not just at iteration start/end, but more frequently or do it per story end basis, and replan again at some important story end, and still have meaningful measure of velocity. It seems like shorter OODA loop, although given my practical situation it seems like I'm dreaming of going to the Moon while still sitting in a cave. :-) Feb 6, 2013 at 18:01
  • 1
    @mrkafk You can't measure without interval, which also implies duration. See also these related definitions of interval. Comments aren't intended for extended discussions, though, so please feel free to ask a related question or move this to PMSE chat.
    – Todd A. Jacobs
    Feb 6, 2013 at 18:30
2

Whether or not you put the incomplete story on the backlog now and then do another iteration now, will not help you now. There is no value to you at this moment to do an iteration.

The value in scrum iterations is that they help you to plan. Look at it this way: if you had been doing small iterations for several months prior to today and had established a predictable velocity, you would likely not be having this problem right now. You probably would have realized the story was too big and could have made better plans. That is the value of doing iterations.

If you are unable to accurately predict a couple weeks worth of work using scrum and small iterations, what hope do you have to predict your work without breaking it down into small iterations?

So, what do you do to solve your current delimma? My answer is to do whatever you need to do to get the work done. If that means to abandon scrum rituals for a while, so be it. Don't follow the rituals blindly -- they are a tool. The overriding goal is to deliver software to the user. Don't let dogma get in the way of delivering great software.

However, when you abandon scrum best practices, do it knowing that you may be sacrificing the long term benefits of scrum. The goal is to get your team to a state of hyperproductivity. You aren't ever going to get there if you can't establish a stable velocity, and you can't establish a stable velocity if you pick and choose when to follow the scrum rituals.

2
  • Hmm so your interpretation is that iteration is little more than "next 2 weeks planning, prediction and verification" tool? That is, it is more like time-boxed WIP limit on stories to see if we plan correctly or not? Feb 6, 2013 at 15:12
  • @mrkafk: What I'm saying is that the scrum process of breaking work down into multiple iterations is designed to be enable you to accurately plan and predict the otherwise difficult-to-predict software development process. Feb 6, 2013 at 15:17
-1

In my opinion you started the iteration incorrectly. Stories included in an iteration should get completed in the same iteration. Either the iteration length was too small or too many stories were added to the iteration. If there are more than one developer in your team then all of the developers should have worked on the same story (instead of one developer) by breaking the story into tasks.

1
  • The story was not very divisible really, it made sense only for one person to do it. And it just so happened that it exceeded iteration while it was planned that it wouldn't. FAIL. But what then, that's exactly the question? Feb 6, 2013 at 15:10
-2

If you do not have an experienced Scrum Master at hand, forget about even trying it...

(you would only create your Scrum-But(t) nightmare)

2
  • OK and what this experienced scrum master should do in context like described? Feb 6, 2013 at 12:39
  • The question is about the practical benefits (if any) of iterations. Your answer doesn't address the question. If you edit your answer, folks will have the option to reconsider any downvotes you may have received.
    – Todd A. Jacobs
    Feb 6, 2013 at 16:08

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.