Having trouble with scope change? Here’s a tip.

Work smarter, better, and faster with weekly tips and how-tos.

I was just writing a response to a question posed on a GreenHopper documentation page. It is worth sharing more broadly as I’ve seen similar queries a few times recently.

The fact that I can drag and drop inside a sprint, from one unstarted sprint to another, from one unstarted to start sprint, but not out of a started sprint is extraordinarily frustrating. Right now for each issue I want to move, I am forced into a baffling 5-click process. Jira seems to follow a pattern of design decisions that favor a strict workflow ideology over basic concerns over user experience and functionality. Atlassian should penalize incorrect workflows passively, by allowing me to do things but give me a note/alert afterwards (“Hey, doing that screws up reporting, next time try organizing your sprints better”) not actively hinder basic functionality like drag-and-drop.

The ability to drag a story out of a current sprint is not something we have included in GreenHopper. However, teams can still remove a story from a current sprint if they really must, as the person above stated. We’re not trying to penalise people in GreenHopper though. We are trying to encourage teams to be more effective and follow ideal behaviour.

In this case we’re encouraging teams to commit to deliver something in a sprint and stick to it. This will help the teams attain predictability over time.

What I’m finding is that some teams are constantly adding stories to, or removing stories from, a current sprint. My normal reaction is: People! Have you no discipline? The reason the team estimates is give them confidence they can deliver what is in that sprint at the end of the sprint. This goes back to one of the principals of Agile – deliver working software frequently.

Why would a team commit to and start a sprint if they didn’t think they could deliver it? An alternative approach is to commit to less, and pull work into a sprint if the team complets every story in the sprint before they thought they would.

Either way, the team can see this scope change in the burndown chart.

When the team removes a story from a sprint in GreenHopper still shows the original commitment on the velocity chart. The velocity chart shows the teams commitment (grey) and delivery (green) for each sprint that has finished. Within 3 – 6 sprints the team should have a pretty good understanding what they can deliver in a sprint.

So, while you may adding stories to, or removing them from, sprints today I encourage you to have more discipline and stop this behaviour. It is not ideal over the long term.

Start by committing to less and I am confident that over time the team will arrive at more appropriate sprint commitments. The upshot is that you will also have more predictability around delivery, which is sure to please customers.

The Atlassian Agile series: This is the latest guest blog by top Agile experts using Atlassian products. Visit atlassian.com/agile for more Agile resources — plus find other interviews including those with Zynga, OpenDNS, OfficeDrop, John Muir Health, PBS, Interspire, and many more.