The story about the rabbit and the cream cheese!

It’s not really about a rabbit and cream cheese, it’s actually a story about user requirements, how they are specified, assumptions and context!

 

A long time ago, I sent my boyfriend a text message and asked him to buy some low fat cream cheese on the way home.

 So what do we think? Clear instruction of what I wanted and when?

 Well no, when I got home he said to me, “you didn’t tell me how much you needed so there’s two packets in the fridge”
 

And in the fridge there were two packets of low fat Dairylea Triangles

Ok, so they are low fat, there is enough for what I needed, and they were purchased on the way home – does this meet my specification?

 Well, after a little debate and looking up the definition of cream cheese, we agreed that does actually meet what I asked for.

 Which means that I was happy right?

Well no. Although I loathingly agreed that that did mean my specification, it was not what I wanted and would be difficult for me to use.

 Why?

 Because actually I was making my pet rabbit a carrot cake for his birthday, and needed cream cheese for the icing.

The actual cream cheese itself would have been ok, but I would have had to open every triangle and scrape the cheese out. Far from ideal!

 So what’s my point?

 Well my point is about context and shared understanding of what is trying to be achieved. Without this information, it is very easy misunderstandings to occur, or for one person to think they know what is meant or wanted, when in fact they don’t.

 In Scrum, instead of saying “Please buy some low fat cream cheese on the way home”, this would have been expressed as a user story

 

Hector would like you to buy 500g of low fat cream on your way home, so that I can make the icing for his birthday carrot cake

 User …. Requirement…. Context

With this additional context information, I like to think that my boyfriend would have made a slightly different choice.

 Potentially of course I could have just asked for 500g of low fat Philadelphia (which is exactly what I wanted) – but there is also danger in being over specific, or guessing the solution rather than telling your development team the problem and letting them find the best solution.

 If Philadelphia hadn’t been available, or there was an own brand equivalent for half the price, then actually, he could have bought me what I needed, without meeting my (too specific) specification.

 I also have another true story – about the project manager and programmer going shopping (which is actually about specifying the solution, rather than outlining the problem/task you are trying to achieve)

 

Returnto GeekSpeak main page

 

  

It’s the way you tell ‘em – User stories vs Requirements

In traditional project manager, someone spends a lot of time putting together a specification, then hand it over to the development team.

Something is developed, there is a big reveal and then faces are pulled, it’s not quite what they wanted!

During a training course we were put in pairs, one person was shown a simple picture made up of shapes, and had to write down instructions as to how to recreate it. The other person then had to try to draw the same picture from just the instructions, without looking at the original, or asking any questions.

We did pretty well, but there was one point of contention – I’d been told to draw a cross in the bottom left hand corner. I deliberated for ages over whether this should be

 

Eventually I went with the one on the right – If  you’d told me to put a cross in the box, this is what I would have drawn, therefore this must be a cross.

I revealed my drawing to my partner who declared “What have you drawn a kiss for!”

Another of his instructions had been to “draw a pac man facing left” – which I did with no issue, much quicker than the people who had long instructions about drawing a circle, with a chunk out of it etc etc

 

 

I think the point of my story is that it is easy to make assumptions,  requirements are hard to describe, often what is clear to one persons (the expert in the field) makes no sense to others.

 

So what’s different about Scrum?  Two things

1.      Requirements are written in a User Story format that provides context
2.       Customer involvement

 

User stories are written in 3 parts User…Requirement…Context

e.g. Manager wants the wall blue, so that it is clear that it is associated with the shop

This is intended to ensure that the requirement will benefit at least one user type, and that there is valid reason for doing it.

 Customer involvement is also key. Scrum encourages co-location and regular conversation and demos. This means that if the developer is unsure which way round a cross should be, they can ask, or alternatively if the customer sees the builder with a colour chart, they can mention they wanted Royal Blue before too much time/paint is wasted.

 

Read a story about the importance of context – the rabbit and the cream cheese!

 Previous section: Focus and the minimal shippable product

 Next section: Turning a good story into a usable backlog

Do you want to build a snowman? (Scrum style)

The basic principle of scrum, is to deliver the absolute bare minimum to make a product do its job, and then develop it incrementally over a number of short sprint periods.
 

Start basic, and then go back to add the bells, whistles, nice to have features and extras afterwards.

It's also worth mentioning that these sprints don't have to run back to back - it's ok to work on other things in between - particularly if this gives your customer time to think about what they need, or find out more information (like decide what colour scarf they'd like)
 

	So if my product is to draw a snowman - in the first sprint I do the minimum possible to make it recognisable Imagine it's pictionary!
	In sprint ii you can start to think about the other features of a snowman, so maybe the hat and scarf, and buttons. As you only have a set amount of time, you'll need to weigh up how much you want each item against how long it will take to implement. In this sprint we could only achieve buttons and a hat, no scarf, so that rolled forward to the next sprint.
	In sprint iii scarf was the top priority, but we also had enough time to start adding "extras" such as stick arms.
	By the time you reach sprint iiii and iv you've already got a well established product. Potentially you should have already stopped, and moved on to something else. However, if you have the business need and the time available - why not add some colour and other embellishments. Just make sure that these do benefit the customer, or at the very least do not irriate people or inhibit use of more essential features.

Minimal shippable product - do "enough" and no more

So in September I started my annual Christmas knitting. Except every year the children get bigger and so the jumpers take longer to make.

This year I planned to make a cardigan for my son featuring holly leaves.

 

 

 

Last week my daughter saw my knitting, asked if I was making her one… it’s hard to say no. My instinct was to put down what I was doing and start a new jumper immediately.

 

If you have 2 jumpers to deliver, is  it better if come Christmas I have two half-finished jumpers, or one complete wearable jumper?

Sometimes trying to keep everyone happy, working on everything at the same time just delays delivery of anything, and may lead to everyone being disappointed.

(and actually it was much better to fess up that I had no chance of making my daughter a jumper in time, and take her to a shop to choose and buy one, than wait until the week before and end up buying two jumpers in a panic because I hadn't finished either!)

 

•      Focus! There is no value until the product is done!
 

 Focusing on what is actually needed is also essential – ideally the cardigan should have little red pompoms between each pair of leaves, but really this is just a  "nice to have".

Although it’s very tempting to sit making pompoms because that’s fun, rather than knitting a plain green sleeve, one is fairly critical to creating a finished product and should be completed first, before the embellishments are added.

Which leads us nicely to the concept of the minimal shippable product…the concept of doing just enough to make it work – ask “is it good enough” for the intended purpose.

Make sure you aren’t designing a Ferrari when all you need is a bike

Work through requirements in priority order and add features incrementally.

Knit your cardigan first, you can always add your pompoms later

Watch my snowman drawing iteratively develop from a minimalshippable product through 5 sprint cycles!

 

Previous section: What’s all this Scrum nonsense

Next section: User stories vs Requirements

Scrum in a nutshell

I wanted a way to quickly and succinctly explain what the agile framework scrum is all about, and try to put across why I’m so passionate about it.

Unfortunately I think my passion has caused it to creep slightly out of nutshell and into a chocolate covered nut selection box, but hopefully it still has some value.

What’s all this scrum nonsense?

A scrum in rugby is an ordered formation of players, used to restart play.

 

 

The scrum agile framework is also intended as a way to keep the game moving and get the ball back into play.

It’s just a different way of controlling projects, that fits particularly well for IT and development projects.

 Managing projects

In projects you usually have 3 variables, time, resource (inc money) and quality

 

 

So if resource and time is no object you can have amazing quality, or if you have a short deadline but loads of money/resource you can still have great quality.

Otherwise there needs to be a trade-off somewhere, do it quick but low quality, or get it quick by adding extra resource.

If you’ve ever worked on an IT project you’ll understand by Scrum was borne out of developer frustration at constantly being nagged at and blamed for work being delivered late, and their perceived inability to be able to commit to when new work can be scheduled for delivery.

 In reality the reason the projects usually overrun or fail is due to poorly defined requirements, lack of customer engagement, scope creep, and developers being forced to spend hours on trivial things just to get the customer to sign off.

 We should also remember that developers are also usually very bright individuals. They don’t take kindly to constantly being interrupted and bugged by Project Managers asking and moaning for things. Particularly when what they are being asked for is completely unachievable to start with, and was never actually something they agreed to.

How many times have you been given a project plan that already has a milestone dates on it before you’ve have any real involvement?

Surely it’s not possible to know when something will be finished before you’ve been asked how much work will be needed from your team or when you might be able to schedule this in?

 

So why is scrum different?

Scrum is different because

•      Fixed time and cost for projects

•      No Project Manager – therefore no micro management (Team is responsible for themselves and customer (product owner) also has responsibilities)

•      Meetings are rare and TIME BOXED! (they can’t overrun)

•      Requirements are clear and prioritised – if they’re not it’s for someone else to deal with (product owner)

•      Focus on one thing for a set period of time – (a sprint) if you’re being distracted, it’s for someone else (Scrum master) to sort out

•      People are forced to really think about what they want and why they want it

•      The whole process is visible - I’ll show the value of this later

 

Ultimately Scrum provides some certainty – we know that we are going to work on one product for a fixed length of time (a sprint) and at the end of that period, we will deliver something.

 We don’t even think about starting work until we have all the requirements laid out, and commitment that the customer will be there if we need to ask questions or demonstrate new features.

 If not everything is delivered in the first sprint, then it is either written off as no longer important, or another sprint is scheduled in the future.

 

Next section:   Focus and the minimal shippable product