Archive for March, 2009

Reasons to Celebrate

2009/03/27

Lionhead Studios wins a BAFTA

Lionhead won best Action & Adventure Game at the BAFTAs!  I get to say I have a credit on a BAFTA winning game!  It makes me even more proud of the team and feel very fortunate to be among their number.

A few days after the awards I organised some of the team together to pose with the BAFTA.  Many thanks to Louise for letting us borrow it for the shoot!  Gave me a chance to use my Nikon D80 SLR for something pretty special.

2009-03-12 DSC_0008 bafta tools team

Someone kindly took a picture of me with it.  You know it’s kind of heavy (in a very good way!)

2009-03-12 DSC_0051 paul e bafta

Unofficial Lionhead Party

I organised a party for Lionhead family, friends and ex-pats back at the end of February.  The night went really well thanks to my wife doing a ton of leg work for it, the Lionhead band organising themselves and a ton of attendees contributing kit for the evening.   I felt it was important to have an event to thank the friends and family who supported all of us during the later part of the development of Fable II.  Although they didn’t work directly on the game their contribution was invaluable.

Everyone was encouraged to bring some food in an American “Pot Luck” style buffet.  Traditional American, Spanish, Greek and English food (including a massive stack of Jaffa Cakes) ended up being on a big table.  We had a bar and a projector shone against a good sized wall used for Rock Band and Lips.  It felt like a fun family get together rather than just a work party.  Someone else can organise the next one though! 🙂

2009-02-28 DSC_0051 rockband test

The highlight of the evening was with out a doubt the Lionhead Band and their great set on stage.  It was their second gig – they were called in at the last moment to provide entertainment for the Christmas party.  Luckily they were already practicing for the unofficial party and I hear that first performance was great (I was visiting the States at the time of that Christmas party).

2009-02-28_lionhead_band_markw

2009-02-28 DSC_0200 lionhead band

I’ll end this post with a link off to a youtube performance recorded of the guys rocking out. 😀

Agile Development – RPS Estimation

2009/03/08

Background

Previous article: https://paulecoyote.wordpress.com/2009/02/22/agile-development-vocabulary

This estimation technique based on a simple game of rock, paper, scissors (RPS) is something we have already experimented with to estimate story points for a task.  A story point is a measure of complexity and size of a task (see Agile – Vocabulary), though could be used to estimated time too.

Rock Paper Scissor Estimation… For the win?

Planning Poker

First of all planning poker seems to be way more documented than rock paper scissors estimation, and there are tons of resources about it already on the web.  If planning poker is not familiar to you I would definitely recommend reading up a little about it.  Feel free to also comment if you have come across another discussion on rock paper scissors used in this way for estimation.

In planning poker each player involved in estimation is given cards with a Fibonacci number on representing how many story points a task is worth.  Sometimes decks use a base 2 binary numeral system – something probably more familiar to many software developers.  These are played face down, and on reveal the highest and lowest guessers talk about their estimation with the other players.  Play continues until the values converge.  The strength of rock paper scissors is no props are necessary!

Roshambo!

The rock paper scissors method has roots in the Delphi and Wideband Delphi methods of estimation – but less formal.

Setup

Make sure the people you are playing with have the same idea about what a unit story point is.  It is best if it is a completed simple task you are all familiar with, otherwise you have to start with an agreed duration of time on a task (e.g. half a day).

Nominate one person to marshal the session.  This might be the scrum master (if you are practicing scrum) but the role should switch between team mates.  Rotating the role allows members of the team to grow in confidence talking with their co-workers, encourages joint ownership of the estimation process and it helps the team to jell.

A list of tasks should be given to the marshal to familiarise him or herself with.  The marshal then arranges the meeting.

Scale

Personally I prefer play with the binary numeral system because it is really easy to remember.  You may prefer the Fibonacci numbers which is fine.  Adjust the scale for larger problems or use both hands. Large amounts of story points indicates that the task estimated should be broken down in to more manageable chunks.

  • 0 Fingers:
  • DSC_0264  - 0 fingers Less than 1 story point
  • 1 Finger:
  • DSC_0259 - 1 finger 1 story point
  • 2 Fingers:
  • DSC_0260 - 2 fingers 2 story points
  • 3 Fingers:
  • DSC_0261  - 3 fingers 4 story points
  • 4 Fingers:
  • DSC_0262  - 4 fingers 8 story points
  • 5 Fingers:
  • DSC_0263  - 5 fingers 12 story points
Play
  1. The marshal introduces a task to the group.  Brief further definition of task might be necessary but the marshal should not allow too much detail to be discussed at this point.  It may sway initial estimates, especially if the perceived senior authority on the subject starts talking about complexity and size too deeply.
  2. Marshal counts to three.  At the count of three everyone presents their hands at the same time to the rest of the group.
  3. The person with the largest estimate explains to the group what made them guess the highest.  This helps to draw out unknown facets of the task.
  4. The person with the lowest estimate explains to the group what made them guess the lowest.  This helps to draw out false assumptions, or perhaps something helpful that could simplify working out the task.
  5. Marshal calls for another round of estimations (back to step 2).  Process repeats until the estimates converge.  Estimates should converge, once they do return to step 1 and repeat for each task.

Scale of tasks can be an issue with this form of estimation using the binary numeral system “is Task X really twice as hard as Task Y?”.  Greater scale accuracy can be achieved by using different combinations of fingers.  If using the binary method that could be holding up different combinations of fingers (thumb and index finger could mean “3” for example).  That has it’s own problems because some combinations of fingers are actually pretty hard to carry off for people with less flexible hands.

The strength of this method is that it does not necessarily even need a formal meeting or marshal.  A group of a few people can easily estimate using this method in a corridor, at a desk, etc.

Links