In our most recent planning and retrospective, we looked at our team’s velocity rate and found that we were committing to more work that we could deliver. I won’t share the ugly details here, but I think we had committed to 50% more than we delivered. On top of that, half of the tasks we delivered came into the sprint after our planning meeting.
Several of us said, “Hey, I did more than that. I just didn’t enter all the things I did.”
Rather than be ashamed of our sad attempts at agile, though, we simply agreed that we could do better, and we decided that our first improvement would be to track our work more prescisly. We agreed to create tasks in Teamwork to reflect everything we do, listing out each task as an agile story with estimated points and low, medium, or high priority that we assign ourselves. (This isnt’ really how agile prioritization works, but one thing at a time.)
We also agreed as a team that we would enter our tasks better, using the model of agile-scrum stories. You remember the formula, right? It’s a simple set of three Ws: Who, What, and Why?
Officially, scrum and agile present this formula from the perspective of developers and tech products.
As a <user> I can <feature> so that <benefit>.
So what does this look like in the reality? Consider my real world story for this article I’m writing. We’ll look at how I kind of botched it, and then we’ll fix the story so it’s more clear.
Here’s what I found on my Teamwork dashboard this morning:
There is so much to learn from my bad example!
My Suck-y Story: Capture retrospective changes to share with the team, write a post for the team about agile stories and agile check-in.
Who: The team
What: Capture retrospective changes to share and write a post about agile stories and agile check-in. [Did I not realize that this is actually two stories instead of one?]
Why: None. [Yeah. I forgot to include that.]
I gave this a medium priority, but it is probably low because I missed my self-appointed deadline and none of you noticed. I gave it 5 points, which seems high. Who knows what I was thinking there? Also, my story is missing a purpose (very bad!) and doesn’t present the task from the user’s perspective (a little bad). Finally, I really have two or three stories here: capture the changes and write a post or two.
Ugh. Sloppy sloppy.
Here are two slightly better stories to replace that half-baked thing I had dropped into Teamwork.
Rewrite 1: The Communications team will have its retrospective goals captured in Teamwork so we can hold ourselves accountable to each other in our new retrospective.
Who: The Communications team
What: Retrospective goals captured in Teamwork
Why: So we can hold ourselves accountable to each other in our new retrospective.
Rewrite 2: The Communications team will have a post about agile stories so we can better create their own stories in Teamwork. (2 points, low priority)
Who: The Communications team
What: A post about agile stories
Why: So we can better create their own stories in Teamwork.
Writing about the post made it nearly instantly clear that I should try to discuss both check-in/stand-up and agile stories. That’s too much for a post. Since you all didn’t seem to have any problem with our new check-ins, I would suggest that a post on checkin-in/stand-up probably isn’t even necessary.
So it’s fairly simple to write a good story, it keeps us focused on the value we are delivering in our work, and it provides us with an opportunity for reflection. I think it is worth pointing out that agile stories should be meaningful reflection, not busy work. Stating the value of our work for an intended audience is a meaningful act of reflection, and reflection is important to us at HEBFDN.
When we take a moment for reflection, And if we can’t state the value of a task, then we should probably ask ourselves if we really need to do it.
Now I’m gonna go mark this story done.