-2

I am some way through a project, on the 3rd sprint, which is about back-end processing. Let;s say the sprint name is "3. Data merging and form generation". I have 4 or 5 features in that sprint relate directly to that task, and I'm halfway though- some completed, some not, one in progress.

While in this sprint, I demonstrated some of what was happening to the client, who promptly (kind of unexpectedly) gave me a few pages of feedback purely to do with the UI. Very front-endy stuff, nothing to do with my current sprint, but still relevant and good stuff.

It seemed that at that time, it would be appropriate to drop my current back-end work and address the feedback. The reason being by addressing the UI issues, it would stop propagation of 'wrongness' to the rest of the application (Lotus Domino: That's how it works).

JIRA doens't have a facility for putting Sprints on hold, and starting a new one. You have to close a sprint.

Adding a feature to my current sprint would be fine, but would include a load of UI issues in a sprint names explicitly to do with the back-end processing.

It felt like square-peg-round-hole, and I'm not sure how this is 'supposed to' go with Agile, or JIRA.

So my question is: Is the problem that ..

  1. Naming of Sprints shouldn't include too much commitment to their nature, so including a UI task with a sprint intended for the back-end processing woudn't be upsetting things.
  2. If a sprint is "interrupted" like this, my notion of putting it on hold and sidetracking to another sprint isn't how Agile works (hence JIRA won't let you). Something else should happen (if so, what?)
  3. JIRA is less flexible than Agile demands (seems very unlikely!)
  4. Some other thing I haven't thought of.
David Makogon
  • 69,407
  • 21
  • 141
  • 189
user2808054
  • 1,376
  • 1
  • 11
  • 19
  • The name of the sprint is not a big deal I feel, though many people prefer to use names such as "Team ABC Sprint 4" without info about what work is in the sprint. – mdoar Nov 03 '16 at 19:58
  • I see the purpose of sprints as defining a small amount of work that you can estimate reasonably well. If there is a serious change in the scope then close the sprint early and start a new one. – mdoar Nov 03 '16 at 19:58
  • @mdoar I see - I think I'm workingout where my confusion lies: Would you say a sprint is more about a timeframe (eg weeks 3-5) or a project work 'area' (eg 'implement validation') – user2808054 Nov 04 '16 at 14:49
  • I'm voting to close this question as off-topic because project-management is off-topic on SO. – BDL Aug 10 '17 at 11:51

1 Answers1

1

The typical approach to scope changes mid-sprint is as follows:

If a change is relatively minor and both the team and the Product Owner agree then you go ahead make it. Typically a team will compensate for any changes, for example when they bring in a new story they would also take out a similarly sized story so that the net effect on the sprint is close to zero.

If the changes are significant the Product Owner may terminate the sprint. The team immediately starts planning for a new sprint in the same manner as usual.

It isn't all that common to name sprints with details of what the sprint contains. Just using a simple numerical sprint name (e.g. sprint 1, sprint 2) can help to make it clear the Scrum team is open to change.

In JIRA, if a sprint was terminated early I would mark it as complete and then create a new sprint. This may mess with your velocity calculation a little, but should be easy enough to compensate for.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • 1
    Thanks Barnaby, this helps a lot. As it happens the changes were non-trivial so the sprint was terminated and a new one 'spawned'. I think the crux of it is the naming of the sprints: the names were tied to specific areas of the project, so seeing the examples you give is very helpful. Thanks ! – user2808054 Nov 08 '16 at 15:55