What’s In a Name? That which we call a developer…

I just saw some comments in a discussion thread about who should be contributing to story sizing when using Planning Poker. The question was about whether or not the Scrum Master should give a size estimate or should just the ‘core’ members give their estimates.

Surprisingly, several people responded and said only people who touch the code should be estimating. Those people are wrong.



Anybody who will do work in order to complete the story should be involved in estimating, whether you’re using Planning Poker, or any other method. Remember, when you’re sizing stories you’re trying to gauge the effort that will be required. Therefore, everybody’s effort should be taken into account.

I think the confusion comes from the fact that so many of us are used to thinking of a developer only as someone who writes code. But Scrum calls anybody who isn’t the Scrum Master or the Product Owner a ‘Developer’. That means testers, BSAs, and anybody else that will contribute to the story getting done is a Developer. But what we call them isn’t the important part. What matters is that the right people are in the room and they arrive at a size that is informed by all perspectives that matter.


Semantic Diffusion

Recently I was on a conference call with several Agile practitioners and the person who usually facilitates the meeting – let’s call him Peter – wasn’t able to be on the call that day. He asked another person to run the meeting for him. As the call got started, the person covering for Peter said, “Peter asked us to self-organize today so let’s get started”.

I winced just a tiny bit when I heard that. Was it necessarily wrong to use the term ‘self-organize’ in this context? Maybe not wrong, but it’s a good example of what Martin Fowler calls Semantic Diffusion. Martin says, “Semantic diffusion occurs when you have a word that is coined by a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition. This weakening risks losing the definition entirely – and with it any usefulness to the term”.

I’m sure some of you might think, “Oh please, get over it. It’s just a word”. To that I say, it’s not just a word, it’s an important word, and an important concept as well. In fact, it’s so fundamental that it’s one of the 12 principles of the Agile Manifesto, “The best architectures, requirements, and designs emerge from self-organizing teams.” A self-organzing team, when faced with a new challenge, figures out how to organize themselves and their work to accomplish the goal. There was no challenge and we weren’t architecting or designing anything. We were just having a simple meeting.

So I encourage you to use words carefully, lest they lose their important meanings.


Name Your User Stories

Even if you’re new to SCRUM, you almost certainly know the popular user story format, ‘As a (type of user) I want (a goal or desire) so that (some benefit is obtained)’. Some people will put the pieces of this structure in a different order so you might see something like, ‘In order to (obtain some benefit), as a (type of user) , I want (a goal or desire)’. Either style is fine.

These ways of writing user stories are popular for good reason. If written well, they can be estimated easily, set the context for further discussion, and are adaptable to change.

Captain Obvious to the rescue

But this canonical format can feel a bit wordy when all you want to do is convey which story you’re referring to in a conversation. There’s a very simple solution that’s often overlooked by some people after they’ve been shown the ‘right’ way to write them. Just add a story name to go along with the fully written version.

Let’s say your story looks like this: ‘As a payment processor, I want to record a payment received from a customer so that they receive credit for the payment’. Now if you want to talk with the team about the story, saying, “Hey, let’s talk about the ‘As a payment processor, I want to record a payment received from a customer’ story” is going to feel like quite a mouthful. But, “Let’s talk about the ‘record a payment’ story” rolls off the tongue a lot easier. This can also make backlog grooming a lot easier because looking at a pile of note cards or a list of stories with the stories fully written out can make your eyes do funny things.

Yeah, yeah, I know. This is so obvious it’s hardly worth mentioning, right? Maybe, but I’ll go out on a limb and say some people’s lives as a PO just got a lot easier.

Shippable: You keep using that word

Shippable. Funny how a simple word can cause so much confusion.

One of the first things you learn when you dive into SCRUM is that the team will produce shippable software at the end of each sprint. At the end of every two weeks I, the product owner, will get to lay my hands on some new features that will work and provide value to the business and that’s great because that’s what I care about. I’m making sure value is being realized each sprint. I could even ship this software (or migrate to production, as the case may be) the day after the sprint ends because these features will be shippable. Fantastic, right?

Whoa there. Not so fast, cowboy.

What’s the problem, you ask? If it’s shippable, why can’t I, you know, ship it? Because when Agile people say shippable, they don’t really mean shippable.

Then what does it mean?

Jeff Patton says that shippable refers to the quality of what’s been built and I think he’s right. It means that it does what it’s intended to do, the code is supported well by unit and acceptance tests, it meets the team’s definition of done (the team has one of those, right?) and is up to the high quality standards of the team such that it could be shipped (or migrated to production) and you’d sleep well, confident that it won’t blow up after it leaves your loving care.

ShippableWait, what’s that? You say you became a Certified Scrum Product Owner and during your [2 days of] training you were told that you’ll work with the team to deliver working, shippable software at the end of each iteration and that, if you wanted to, you could deliver it to users at a moment’s notice?

No, you probably weren’t. At least I hope you weren’t because much of the time, especially early in a project, it’s not even possible. C’mon, think about it. Say you’re building a new system from scratch. You don’t really think you could build enough functionality in your first sprint to release it, do you? Of course you don’t. So if you’re new to this, don’t worry when you finish a sprint with a feature that isn’t fully baked. Many times there are very good reasons to be in this position at the end of a sprint.

Let’s take a very simplified example to illustrate what you don’t want to get caught up on when it comes to producing shippable software.

Say you’re building a web application. It’s early on in the project and you’ve got a couple of basic pages already created, but there’s much more work in front of you than there is behind you. You’ve got a fistful of user stories and to satisfy the needs those stories represent, you and the team have decided you will need to create a new page that will have three widgets on it.  You and the team know those widgets are going to be very challenging to create. To make matters worse, if you don’t get the widgets right, your users are going to be very, very unhappy. These are very important widgets, got it?

You decide you want to take on these risky stories in your next sprint so that if there are going to be any surprises, you can flush them out now and deal with them.  Then someone on the team pipes up and says, “Hey, wait. We forgot about that little user story we have about making it possible for the user to navigate to our new page of widgets. We have to do that story in this sprint too, otherwise our product won’t be shippable because the users won’t be able to get to the widget page.”

Easy now, don’t panic. Why? Simple – you’re not going to ship it right after the sprint ends so that’s not your biggest concern right now. Your biggest concern is making sure these difficult (read: risky) widgets get done and work as expected. You can worry about navigation later.

But be careful because I’m not suggesting you don’t ever need to be concerned with being in a truly shippable state. In fact, the more you deviate from that state the more risk you’re assuming. Business priorities can, and do, change on a dime. If they do change, you could get a call at any time telling you to wrap up whatever you’re doing on the project and release the product into production immediately. So although you’ve probably got some flexibility, always keep your short-term goals in sight. If you’ve got a release date set for your widgets, and I hope you do, then you’ll need to manage the backlog properly so that you’ll get to those navigation stories in time for them to be completed and in your release.