Search code examples
jiraproject-managementagilejira-agile

JIRA/Agile: Wrong Sprint naming ? Or wrong methodology? Or ..?

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.
Solution

  • 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.