I saw the following series of snippets in a LinkedIn discussion on the Agile ALM tool Rally. Bear with me as you read through them to get the context for our discussion…
Original Question
I have a serious case of "I want to get back to JIRA Agile".
My latest challenge with Rally is to find the best and most true way of dealing with unfinished stories at the end of a sprint.
Story: I as a ScrumMaster want to move 3 unfinished stories from Sprint 1 to Sprint 2 gracefully so that the team will have these stories in the next sprint without falsifying the velocity of Sprint 2 or the backlog and not creating any more overhead for the ScrumMaster.
Acceptance Criteria:
- Total backlog story points stays true
- Velocity of previous sprint stays true (commitment is reflected accurately)
- it's not adding a huge amount of overhead on the ScrumMaster or the person doing it
- It doesn't need a custom app for doing this
Looking forward to your feedback!Reply #1
A slight modification on the above. We split the story (which actually creates a parent and another child) then Rally will automatically split the completed and incomplete tasks. Then, and very important, set the Unfinished story points to 0. Rally assigns the original points to each sibling. This will create the illusion of a greater velocity that actual. Some people allocate the points, but I am of the opinion "Done or Not Done" (There is no Try!)
Mark the Unfinished story as Complete but not Accepted. Then when the Continued sibling is complete and accepted, go back and accept the unfinished sibling. This way the Feature %done is accurate. I suspect that the parent is not counted in the story count, but I'd have to check.Reply #2
This is a tough one. Rally's splitting solution is a good idea for other things, but there is always a trade off with the implementation for rolling over stories from sprint to sprint. Two stories are created with identical points under an epic, and any project scope reports are doubled. If you make the story zero points, you still need to mess with the state to ensure it does not impact feature stats. Until rally creates a way that a story was "historically" in sprint 1 and is now in sprint 2 ( as the same story) you will need to make trade offs.
I typically just move the story forward because I am mostly concerned about work completed, not what was not accepted after the sprint is closed. I find the need to know what was in a missed by the team is only valuable for the retrospective. Not beyond. I keep an external spreadsheet of committed vs earned points outside of Rally for stats only so the team can see if they constantly over/under commit. Not story rehashing.
Reactions
My first reaction is how a tool, any tool, can take over the conversations within agile teams. Here the functionality of the tool is driving much of the thinking of three leaders within their respective agile team contexts.
They also seem to be worrying a great deal about the “reporting”. Are they fairly representing the velocity/points and will observers get the “right” impression from examining the trends?
This is an example of why I don’t like “leading with” tools in the first place. Instead of focusing on effective agile principles and practices, we end up worrying too much about the tool and the data reporting.
How I handle un-Done Work
I know this may be a little severe, but I’ll share with you how I like to handle un-done work. I’ve been doing it this way for 10+ years. Don’t necessarily know where or when I started it nor who influenced me in this direction. I think it’s what’s recommended in most basic agile project management books, but I don’t have a solid reference off the top of my head.
Here we go:
- IF a User Story isn’t complete (to a team’s Definition of Done) then they get NO CREDIT for any of the story points in the current sprint;
- IF the Product Owner decides the story warrants it, it will move to the next sprint (complete it OR remove it);
- In their Retrospective, the team discusses how to get better at committing to realistic goals and finishing their work;
- In Sprint Planning, the team plans the remaining work to cleanup or finish the story;
- When the story is complete in the next sprint, the team realizes all of the story points.
Basically this model reinforces the notions of:
- Team receives no partial credit for incomplete work
- Team commits to a body of work within a sprint and delivers it (or more)
- Team makes their work and dynamics transparent
- Team strives for continuous improvement
As I try to influence each team towards base agile principles. And yes, I understand that most agile tools struggle with this notion. They typically want to “split” the story from an “accounting” perspective.
Arguments
I always receive arguments about this approach.
First and foremost is the affect it has on team velocity. Clearly if a team has an average velocity of 25 and misses an 8 point story then their velocity might be 17 points and then 33 points in subsequent sprints. This “turbulence” will be clearly visible to everyone and will probably cause uncomfortable conversations. It’s ugly. It makes stakeholders pay attention. It makes predictability and forecasting hard.
Exactly!
Another argument is that the team will become demoralized.
Why? They clearly struggled a bit with this story and need to reevaluate their estimation and work planning. So what? That happens with newer teams and this event will create healthy discussions and adjustments in their retrospectives.
From my perspective, it all boils down to arithmetic. It didn’t work out, so we have a decision. Do we split the story and take partial credit—hiding the issue OR do we just handle it congruently, move on, and strive to get better next time?
SideBar Story
I once coached an organization where each of their teams had about 25% of each sprints stories remain incomplete at the end of each sprint. It happened so often that they created a term for them—Continuation Stories.
It got even worse. Continuation Stories had a tendency to cascade across more than one Sprint. In fact, on average they spanned 3-4 sprints before they finally were completed and considered “Done”.
Because they “split” the work at the end of each sprint, their velocity appears sound. And because Continuation Stories, became the norm, they really didn’t talk about them much in retrospective.
However, their customers were paying attention and realized that 25% of each sprint was missing. Not only that, but undone work crept into subsequent sprints and continuously undermined the amount of work the team was delivering.
Point being—it was noticed and it wasn’t “good”.
Wrapping Up
I’ve wanted to discuss story splitting as a result of execution and delivery dynamics for quite some time. I think another discussion on a Rally forum was the initiator then as well.
It’s not that the tools are bad. But it is the fact that they encourage us to focus on the “arithmetic” rather than the behaviors we want to instill and inspire in our agile teams.
In this case, I don’t care about the interpretation of velocity or the reactions to turbulence. It happens. What I want the team to focus on is (1) hold firmly to their Definition of Done, (2) if something isn’t completed, determine what happened – exploring root cause(s) and then (3) do something about it to improve their abilities to plan and deliver on their future commitments.
Whether you “split” your stories or not, I hope this article caused you to pause and consider how you handle partially completed work within your sprints.
Stay agile my friends,
Bob.