agile

1+3 != 4

Please stop adding story points

“I’m not sure if I was the inventor of story points, but if I am, I’m sorry” – Ron Jeffries

What is a story point

At their heart story points are an estimate of how much effort/complexity a piece of functionality is to deliver. This estimate is often represented as a number.

That’s fine, but please stop adding estimates!

Let’s say you use Fibonacci numbers to define your story points;

  • A 1 point story could be a trivial change, like fixing a typo
  • A 3 point story could well be something more involved, say adding a couple of textboxes to a website page, and persisting the data entered in them.

How much work is that?

If you have 2 stories, one estimated at 3 points and one at 1 point, how many story points is that? A total of 4 points is something I have heard.

Now, what if I have 10 stories, all sized at 1 point. By this logic we have a total of 10 story points. Nothing wrong with this, assuming the only goal for adding the story points is to re-affirm en elementary grasp of numbers. It gets funny if… you want to know how long the project will take to complete, based on this.

Week 1, we complete only 3 point stories, and complete 5 of these in 5 days.

Week 2, we complete only 1 point stories, and complete 100 of these in 5 days.

I have seen this interpreted as, in 10 days, 105 story points delivered, averaging a velocity of 52.5 story point per week. The sized backlog, stands at 150sp, so all should be complete in approx 3 weeks.

Spread the points

mathsHopefully you can see the problem here.  We can deliver small stories really fast and bigger stories, slow.

In the above example, the longest 3 point story took 2 days to deliver. The longest 1 point story took 3 hours.

The shortest 3 point story took 3 hours and the shortest, 1 point story, took 0.5 hours.

The backlog, has 99 one point stories and 17 three point stories (150 story points, mentioned earlier), so the longest time to complete could be:
99*3hrs (297) + 17*12 (204) = 501hrs = 83 days.

Optimistic time is:
 0.5*99 (50) + 17*3 (51) = 101hrs  = 25 days

At this stage I wonder if I’m writing a maths blog… Lots of numbers here, all based on, an estimate! Some people make the mistake of aiming to deliver n story points per sprint, and when stories are not delivered post mortems happen, to see what went wrong.

“I smell something fishy and I’m not talking about the contents of Baldrick’s apple crumble.” – Blackadder

Nonsense, the lot of it. The only way you can deliver a consistent number of story points per iteration, is if all those stories are the same size and your team’s ability to estimate (and create stories) that are the same size is amazing.

Keep it simple

If every story is enhancing your product (as they should), at the end of your iteration some stories will be ‘done’ and you will have enhanced your product. Story points can be used for getting a feel for the size (complexity/amount of work) a story is. This is useful to the product owner to see how much effort a requested feature is, to help with their prioritisation. It’s also useful if you want to ensure you only take stories of a certain size into your iteration (i.e. a max of 3, say), encouraging story splitting. Story points have other benefits too, but for ‘big’ releases and tracking story point burn up/down/velocity… please stop.

In football the only statistic that matter is the score line; in software, it’s what’s delivered.

Image Credit: Pranav Yaddanapudi

Advertisements

Write Less, Test More (part 2)

In my previous post I blogged about Xunit Theories, which provided a neat way to pass multiple test scenarios into one test method. Why I’m liking Xunit these days is due to its extensibility. In particular Adam Ralph and friends have extended it and come up with Xbehave.Net.

A popular pattern when testing is Given (my input), When (I test this), Then (expect this outcome). See Cucumber scenarios for more info. One of the problems with my last post is that the [Fact] didn’t use this language. The test output didn’t use this language. Wouldn’t it be nice if it did?

If we wrote that test with xBehave it would. This post revisits the problem from the first post and shows how we could test it using xBehave.Net.

Problem Recap

I want a class that, when given a sentence, will return a collection of strings containing all words in lowercase. This collection should only have alpha characters in it – i.e. spaces and punctuation are to be ignored.

To write our test for the zero case, using xBehave it could look like:

[Scenario]
public void FindWordsEmptyStringScenario(string input, IEnumerable output)
{
"Given an Empty String"
   .Given(() => input = string.Empty);

"When I find words in this string"
   .When(() => output = _wordFinder.FindAllWordsInLowerCase(input));

"Then I expect the answer to be an empty list"
   .Then(() => Assert.Empty(output));
}

Cucumber uses scenarios, so does our test. The test method, takes as its inputs an input and output variable. The method cleanly has three calls, each coming off a string describing the action:
Spelling it out, the Given() sets up our input variable.
When(), does the business of calling our method under test, returning the output, into our variable, called output.
Then(), asserts if the output is what we expected.

Talk about readable!

It gets better – run this through reSharper and our output looks like:

zero_xunit

Again very readable I think.

As I’m sure you guessed, this framework supports something very similar to Xunit’s [InlineData]. It has examples.

Our test scenario, with all example inputs and outputs, based on first blog, looks like

[Scenario]
[Example("", new string[0])]
[Example("One", new [] { "one" })]
[Example("One two", new[] { "one", "two" })]
[Example("One...:; - ,two", new[] { "one", "two" })]
public void FindAllWordsInLowerCaseScenario(string input, string[] expectedOutput, IEnumerable output)
{
    "Given the sentence '{0}'"
        .Given(() => { });

    "When I find words in this sentence"
        .When(() => output = _wordFinder.FindAllWordsInLowerCase(input));

    string.Format("Then I expect the answer to be [{0}]", string.Join(",", expectedOutput))
        .Then(() => Assert.Equal(expectedOutput, output));
}

What’s nice here is that if you remember the outputs from the InLine tests – it didn’t output the expected string arrays’ content. Here, as the method name that gets generated for the test runner output is simply a string we can manipulate the string to show the contents of the expected array.

all_xunit

Each example provided effectively creates a new scenario, which are grouped in the output by scenarioNumber.StepNumber.

For the output names to be neatly formatted here (without repetition of the input variables) we are setting the attribute [OmitArgumentsFromScenarioNames] on the class, which suppresses them.

The Distributed Office

For the past six months I’ve been contracted to a company whose entire dev team work from home. Having done it for this length of time I can say it really works and I’m a little surprised that more dev teams don’t work this way as I think it offers many advantages over conventional office-based working.

Peanut Butter Sales Not Up

For many people, the idea of working from home has become synonymous with sitting around in your underpants in the middle of the day watching Diagnosis Murder, with a hand caked in peanut butter in said pants.
Even the local mayor, Boris Johnson recently accused home workers of being skivers

We all know that is basically sitting wondering whether to go down to the fridge to hack off that bit of cheese before checking your emails again

full Story

Reality

I would argue I’m more productive now – working from home – than I was in offices of old. My working day starts on average anytime between 8 and 9 and finishes sometime between 5 and 6 – this element is very similar to my office-based working time.

Agile

My current project is being delivered using agile methodologies (scrum) – for us that means we have daily scrums, sprint planning, pre-planning, retrospectives and frequent collaborations with the customer. Meetings are done primarily over skype; this works much better than some of my previous experiences of being in a meeting room with a ‘spider’ phone the remote worker communicating over the phone. The reality was often that person often didn’t hear everything and equally it was often hard to make out what they were saying. With a Skype meeting everyone (assuming their internet connection is ok) can hear everyone else and urls can be shared very easily.

Scrum WhiteBoards, Peer Programming, meeting ‘boards’

One advantage the office-based environment has is its physical properties – like whiteboards. Quite a few dev teams love their scrum boards – be it a whiteboard depicting burndown/stories in progress, or a board filled with post-it notes representing stories/tasks for the team with that near golden star feeling for moving said items forwards during a scrum update. Personally I think such dev teams are missing the point of being a dev team; I’ve spent my life as a developer writing software – whose main agenda is to make peoples’ lives easier. Moving people away from pen and paper based systems to windows apps and web-based apps. I have a problem being a developer doing such a task, but then using an antediluvian system to facilitate this. There are many web-based scrum whiteboards out there – we’re using epiServer’s Scrum Dashboard (sitting on top of TFS to manage our backlog), it’s free and does a good job.


Scrum Dashboard

Meeting Boards – by this I mean being in a meeting room and either enduring a laptop hooked up to a projector, projecting a slightly out of focus, crooked image of the user’s desktop to form the focus of a presentation or what not. On top of this I’ve often witnessed the painful hilarity of them failing to get their laptop connected to the network, or just running out of power. In the distributed office you don’t have to suffer this throw back from the 90s. We simply use Join.Me – a fantastic tiny bit of software that lets you share your desktop over the internet. Truly awesome.

Pair programming – Again, we use the fantastic join.me, so the developer doing the typing can share their screen and the other person can sit back, see the other dev’s screen and tell them what to type. Have done this a few times in the current contract and it really works well – esp. if you are the one telling the other what/how to type the code as you can’t just ‘jump in’ as you might when pairing around one desktop, forcing you to articulate what you want the code to do.

Communication

This is one of the weaker elements of having an entire team that’s home based. Communicating to the person(s) you want is fine, Skype handles this need perfectly. What you can miss is what you overhear in an office environment, esp. when the scrum team sits together. The downside is you don’t hear all the conversations, so not all knowledge is shared as easily as it can be. The solution is to share any gems/big decisions that are made without the whole collection of devs being present with the team afterwards. The flaw to this is of course knowing when to share.

One Goal

However, the reason this works is not due to great tools. Success in any project is down to the people and their enthusiasm to achieve the same goal, together. We all work on the same code base and all want to see it’s functionality grow whilst maintaining its high coding standards. We have just increased to 10 developers, in order to develop the product and create a good code base there has to be constant communication both within the sprint teams and across all the devs. A lot of this chat is over Skype’s IM – I don’t think that’s relevant. What is important, is all the developers being passionate about the code base, devoted to producing the product that the customer’s paid for and having that constant communication to help feel we are not remote workers, working on isolated pieces of code but part of a bigger team delivering software.