25 March 2017

Well defined tickets and MVP

An interesting thing happened this week. It seems I did too much work on a ticket.

Wait, you did X and Y? That ticket was only supposed to be X, we have a ticket for Y in our backlog.

Re-reading the ticket for X (which was the so-called "MVP" (Minimum Viable Product)), with this new knowledge fresh in my mind, I still couldn't see where I went wrong. The ticket had decent detail, and actually references Y (the work, not the ticket) within it.

Oh, that should probably have been removed.


So, I essentially ended up doing two tickets of work in this one ticket. While I technically made a mistake, and will learn from it, I still stand by my actions based upon the definition of the ticket.

You may wonder where the problem is with this. We're now ahead, surely? Well, yes, and no. It's more complex than that.

The codebase is ahead, true. However there's the potential that since X and Y were combined, some event/understanding/rethinking that may've happened between them that affects how Y is done, now won't be applied. Also, my time spent on Y might have been better spent on other work - this comes on to "MVP" which I'll go over shortly.

Our poor overworked QA team now has more functionality to test than they originally planned for that ticket (although, in this case, not all that much more).

This leads on to a number of interesting thoughts.

  • Perhaps the MVP wasn't appropriate in this case, perhaps closer to "Minimum Product". We already had the support functionality implemented for the full product, so how does it help us to not do it all? It wasn't that much more work, just tying components together. Otherwise we'd end up finishing a product that isn't technically viable until Y is implemented, extending timescales. It's very easy to lose sight of what exactly is "Viable". Sometimes, in my opinion, if a 20 story-point ticket simply cannot be broken down into smaller viable chunks, then it just has to be done as a 20 story-pointer. (this ticket in question was an 8, in case you're interested, which I felt was appropriate for the full amount of work!)
  • The ticket was clearly misleading, referencing Y when it shouldn't. I hold my hand up and say I should've discussed the ticket with the stakeholder when I picked it up ("The Three C's" - Card, Conversation, Confirmation), so that was mistake on my part. However the ticket seemed fairly clear to me at the time, and even afterwards.
  • It's amazing how much can be achieved when more is expected. I didn't feel stressed, I just got on with it, and it wasn't a rushed implementation.

Final Thoughts

In our retrospective, we added an action point to spend more time properly defining our tickets. Everyone agreed - this wasn't the only example of confusion.

Yes, tickets should be a prompt to speak to stakeholders when it's picked up to clarify the requirements. However, the scope of the ticket should be fairly clear from the definition, otherwise how could it be reasonably estimated?

(As an aside, there's an interesting new approach being presented regarding estimation, which is... don't do it. I'm oversimplifying, but that's the basis of the so-called #NoEstimates "movement". There are some good points made, particularly about the limited value of even considering estimating tickets way down in your backlog (that you'll probably never get to), but I'm not yet fully convinced it would work. I'm curious to experiment with it though.)

What "MVP" actually means should be revisited. Just because a piece of work can be broken down into separate deliverables, does it make sense to? Think about it this way.

If we were taken off the project tomorrow, and didn't get Y done, would X be reasonable and appropriate to deliver by itself?

If the answer to that makes your skin crawl, perhaps it's not true MVP.

No comments:

Post a Comment