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.

Developers!

Developers!

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.

Advertisements

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.