Monday, March 26, 2018

What is a commitment anyway?

Or: The difference between “having committed to something” and “being committed to something.”

This is not about the old story of the chicken and the pig who want to open a restaurant. Even though Ken Schwaber used this adage to illustrate the difference between commitment and involvement in the early days of Scrum, it is no longer part of the canon.

The version history of the scrum guide makes that quite explicit:

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.”

Still I see the term “commitment of the team” quite often. In publications and in ‘real life.’

I have to confess, I am even guilty of using it myself from time to time.

Like with many things in the world, the question is how we use them. In this case it is the question of how we use the term – and the concept – commitment?

There is a fine line, but a very important distinction in who does the committing. A while back I heard some General in a movie say that he “committed 20 troops” to some task. In yet another movie a team member explained the success of his team with the fact that “the whole team was committed to the cause.” So does that mean that the 20 people the General committed to the task will feel commitment to the task and thus succeed? Probably not.

And yet the statement “The team is committed to the sprint goal” is syntactically the same wether the team has committed to the sprint goal (e.g. each team member bought into it) or has been committed to the sprint goal (e.g. some higher authority spoke on behalf of the team without their consent).

till next time
  Michael Mahlberg

P.S.: But then again you might want to consider exchanging iteration based approaches with a flow-based concept and cadences and then you might consider “Department Y will be able to sell product X via channel C” as an idea for a MMF (Minimum Marketable Feature(set))

Monday, March 12, 2018

This is not an Epic

This is a rant...

In a “recent” post Mike Cohn outlines some of the misunderstandings around the the terms «epic», «user story» and «theme».

This article is actually only “kind of” brand new - it is from 2011.

But thanks to the prevalence of Tools and Process over Individuals and Interactions that has been brought to us by tools like Jira for more than ten years now, it seems to me that it is a good idea to look at a few key points again.

For example Mike says:

There's no magic threshold at which we call a particular story an epic. It just means "big user story."

So, sorry folks: an epic does not group a bunch of requirements that do not deliver value on their own together. According to Mike’s old post an epic simply is a story that “[one] didn't get the chance to break […] down into stories that are […] small enough […].”

That’s why it is such a good idea (at least IMHO) to do whatever you like with that “Epic” thingy in Jira – use it to mark other stories, use it as a theme (see Mike’s post for a short explanation of that) use it to signal states if you don’t have a Jira admin in your team etc.

But whatever you choose to do, don’t do functional decomposition by making your epic an enumeration of sub-functions that only deliver value if they are all implemented together.

...end of rant.

till next time
  Michael Mahlberg