Print your spreadsheet based User Stories

As I’ve mentioned in the past and spoken about at the London Scrum gathering, you should have a physical sprint backlog. The reasons are numerous; from being information radiators, to helping define a team culture. However, managing a large backlog of stories, especially if you have multiple backlogs for multiple projects, does become a challenge when trying to keep this information in a physical space.

Where I am right now, we manage our product backlogs using Google Docs. This works for us as it allows for flexibility when prioritising, we can move from room to room and, means we don’t have a large, messy surface of stories (although, I’m convinced this would help us – watch this space). One thing we do suffer from, is the transition of these stories stored digitally, to stories stored on a sprint backlog physically. Writing the stories by hand does mean there are sometimes further conversations around the stories, which is no bad thing, but it also means that often detail is missed from the cards, which causes problems later. This is due to the stories being written in a shortened form and, unfortunately often, a complete lack of acceptance criteria.

So, because of this, I put on my developers hat and created the Story Printer. This is a simple web-app, which allows you to upload a .CSV file and have it turned into printable story cards. At the moment, it’s very simple, but I’ve a few extra things on the roadmap which will add more useful features. But, for now, it does what it says on the tin.

Using the Story Printer, we now have a sprint backlog, with story cards that are identical to the stories in the backlog. Time will tell whether this prototype will prove useful.

Feel free to use it yourself and please contact me with new features, bugs or other stuff. I’d love to know if you use it, or would find it useful with additional features.

Screen grab of story printer
The Story Printer
Advertisements

Resourcing, it's just an estimate OK?

Reign of the Supermen by fengschwing
Reign of the Supermen by fengschwing
It is NOT an indicator of how much work the team is doing, right?

Too often, businesses seem to think that the resourcing we do during sprint planning to work out how many ideal hours we have, allowing us to decide what we can fit into a sprint, is an accurate reflection of how much work the team can/will do.

It’s not, OK, chill out. At BEST it’s a worse case scenario.

The average work day is 7.5 hours. That does not mean that I can dedicate 7.5 hours of work to tasks from the board. When we used to do resourcing, the business would estimate our resourcing for us:

There are seven people on the team doing a two week sprint, therefore, you have 490 man hours in this sprint, fit stories and tasks in that equate to those hours, you can have 15% of that figure for bugs.
-Somebody from the business

We quickly realised (well, as a team, we realised this was wrong immediately, but the business will always wait for empirical evidence first) that this wasn’t going to work. There is no way each team member can dedicate seven hours a day to the sprint. There are numerous things that vie for your time; getting a coffee, taking a piss, talking to colleagues, talking to the business, researching your industry, emailing your wife, checking your bank balance, rebooting your Windoze computer on a AD network which takes about 15 minutes, getting a coffee, etc, etc.

So, sprint after sprint failed (let me be clear, the sprints didn’t “fail” as the business always decided we “drop” something low priority from a sprint before the end but, as a team, that feels like a failure) and this could be down to bad estimating of ideal hours for tasks, true, but this is compounded by bad resourcing.

If you resource incorrectly, your entire sprint is undermined as it’s the basis for deciding what you commit to, you have an inflated idea of how many ideal hours you can deliver and so you over commit. Your gut feeling is always “this is too much work, we’re overcommitting!” but the math is right? So, it should fit in, right? RIGHT?

No, wrong. It won’t. Neither will pretending it will fit in and then dropping stories at a later stage work either. This will undermine the teams ability to deliver quality working software as there is always this grey cloud of unachievable stories hanging on like a bad smell at the end of your sprint backlog. The team will inevitably rush through what they’re doing to try and deliver what they’ve (been forced to) commit to. This is bad on many quite obvious levels, so I won’t spell them all out…

… OK, I will. This will result in less than polished code, rushed, hurried unit tests. Bothered and harrassed QA roles (if you have them) a stressed release manager as he’ll be backward and forward with UAT, an annoyed stakeholder as the stories get rushed, other annoyed stakeholders as their stories get dropped and, finally, a shoddy release of badly written, implemented, tested and released code.

Exaggeration? Maybe. But it makes my point.

If you ask each team member “How many hours a day can you commit to, ideally?” when you’re resourcing. You’ll get a worst case scenario on the amount of ideal hours you have. If you then estimate and plan based on that, you’ll ALWAYS deliver what you commit to (unless you get the planning REALLY wrong) and, usually, have time at the end to pick up an extra story, fix an extra bug, research a new technology or whatever. Everyone wins; the team are happy that they’ve delivered what they’ve said they would (and, maybe more) and the business is happy as they’ve managed external expectations and delivered the commitments and perhaps even more happy if another story was squeezed in, or an extra bug or two squashed.

I understand that you need to know where inefficiencies are, I really do, I want to know also. If the team are kicking around spending three hours a day reading XKCD and reading LOLCats, then I want to know as well and why. But they aren’t they’re spending the time doing actual work. So, let them do it and don’t force them into it.

If you want to measure time spent on things other than the sprint, then use something other than the sprint to measure that time. Resourcing and estimating/planning won’t help you here as they are, after all, just estimates.

Resourcing, it’s just an estimate OK?

Reign of the Supermen by fengschwing
Reign of the Supermen by fengschwing
It is NOT an indicator of how much work the team is doing, right?

Too often, businesses seem to think that the resourcing we do during sprint planning to work out how many ideal hours we have, allowing us to decide what we can fit into a sprint, is an accurate reflection of how much work the team can/will do.

It’s not, OK, chill out. At BEST it’s a worse case scenario.

The average work day is 7.5 hours. That does not mean that I can dedicate 7.5 hours of work to tasks from the board. When we used to do resourcing, the business would estimate our resourcing for us:

There are seven people on the team doing a two week sprint, therefore, you have 490 man hours in this sprint, fit stories and tasks in that equate to those hours, you can have 15% of that figure for bugs.
-Somebody from the business

We quickly realised (well, as a team, we realised this was wrong immediately, but the business will always wait for empirical evidence first) that this wasn’t going to work. There is no way each team member can dedicate seven hours a day to the sprint. There are numerous things that vie for your time; getting a coffee, taking a piss, talking to colleagues, talking to the business, researching your industry, emailing your wife, checking your bank balance, rebooting your Windoze computer on a AD network which takes about 15 minutes, getting a coffee, etc, etc.

So, sprint after sprint failed (let me be clear, the sprints didn’t “fail” as the business always decided we “drop” something low priority from a sprint before the end but, as a team, that feels like a failure) and this could be down to bad estimating of ideal hours for tasks, true, but this is compounded by bad resourcing.

If you resource incorrectly, your entire sprint is undermined as it’s the basis for deciding what you commit to, you have an inflated idea of how many ideal hours you can deliver and so you over commit. Your gut feeling is always “this is too much work, we’re overcommitting!” but the math is right? So, it should fit in, right? RIGHT?

No, wrong. It won’t. Neither will pretending it will fit in and then dropping stories at a later stage work either. This will undermine the teams ability to deliver quality working software as there is always this grey cloud of unachievable stories hanging on like a bad smell at the end of your sprint backlog. The team will inevitably rush through what they’re doing to try and deliver what they’ve (been forced to) commit to. This is bad on many quite obvious levels, so I won’t spell them all out…

… OK, I will. This will result in less than polished code, rushed, hurried unit tests. Bothered and harrassed QA roles (if you have them) a stressed release manager as he’ll be backward and forward with UAT, an annoyed stakeholder as the stories get rushed, other annoyed stakeholders as their stories get dropped and, finally, a shoddy release of badly written, implemented, tested and released code.

Exaggeration? Maybe. But it makes my point.

If you ask each team member “How many hours a day can you commit to, ideally?” when you’re resourcing. You’ll get a worst case scenario on the amount of ideal hours you have. If you then estimate and plan based on that, you’ll ALWAYS deliver what you commit to (unless you get the planning REALLY wrong) and, usually, have time at the end to pick up an extra story, fix an extra bug, research a new technology or whatever. Everyone wins; the team are happy that they’ve delivered what they’ve said they would (and, maybe more) and the business is happy as they’ve managed external expectations and delivered the commitments and perhaps even more happy if another story was squeezed in, or an extra bug or two squashed.

I understand that you need to know where inefficiencies are, I really do, I want to know also. If the team are kicking around spending three hours a day reading XKCD and reading LOLCats, then I want to know as well and why. But they aren’t they’re spending the time doing actual work. So, let them do it and don’t force them into it.

If you want to measure time spent on things other than the sprint, then use something other than the sprint to measure that time. Resourcing and estimating/planning won’t help you here as they are, after all, just estimates.

Estimate like you mean it

Scrum says that planning poker should be short, snappy, time boxed and fairly rough. The more ambiguous the stories, the higher the number on the Fibonacci scale. This is great, it allows you to discuss the story at some length, make sure you’re all on the same page and then throw up a number.

What if your team doesn’t understand every aspect of the project? If you’re new to scrum, or you’ve got silo’d ‘specialists’ for different segments of your product or company (and, honestly, who hasn’t?), or you’ve got a new team member, perhaps a new hire, or someone from another team altogether, then planning poker might not be the most productive hour of your week. You might need to spend time during planning discussing what the story is, how the section of the product or application works and why. That’s going to eat into your timebox for discussing the actual story. So, how do you get round the fact your team isn’t all fully aware of the entire application, or even, in some cases, the part of the application your team is assigned to?

You could just go for it anyway, you might get lucky and everyone estimates the same anyway, your velocity may change, perhaps, but it’d stabalise in the end. Or you could run some workshops to get the new team members or those unfamiliar up to speed with the product, but that eats into your sprint time.

Or, you could send out the story ahead of time and let the team members spend some time pondering it before poker. Email or print and drop on each persons desk a list of the stories (which should be well defined and adhere to the I.N.V.E.S.T acronym) and let the team spend some time getting a feel for them. Those that are most familiar with the project can scan through to see if there’s anything out of the ordinary and those less familiar can spend a little time asking other members of the team, or even getting acquainted with the code. Up close and personal like. That way, when you come to planning, your timeboxes could, if you wanted, be that much shorter and your estimating should be more accurate, making the entire process a bit more solid. As more accurate estimates lead to confidence in committing to stories, lead to delivering what was committed to, leads to sticking to a release plan, leads to the team being full of WINN!Of course, this does all assume that your stories are well defined…