Month: May 2011

Agile Q&A: Wording User Stories

/ Craig Smith / 1 Comment

A former colleague contacted me the other day with a question along the lines of:

I am working with some guys who are looking at creating User Stories and there is a lot of discussion about how they should be worded. When a call comes into the business, the call centre need to search for the details of the person being queried.  The search may be on an identification number, name, date of birth etc etc. Is the user story:

As a call centre consultant I need to search for a customer so that I can process a customer update.

On the back will be the various search options that could be employed such as by company name, customer name, identification umber, date of birth, address, etc.

Or is it:

As a call centre consultant I need to search for a customer by company name so that I can process a customer update

As a call centre consultant I need to search for a customer by identification number so that I can process a customer update

As a call centre consultant I need to search for a customer by customer name so that I can process a customer update

There is no official right or wrong for user stories, except to remember that they are a “promise for a conversation” and that every story should follow the INVEST model:

Independent
Negotiable
Valuable
Estimable
Small
Testable

They also more valuable if written in the As a… I need… So that format, but the above examples already have that covered.

So if you apply that logic to the first example, it could fall down on some of these. If one or many search types are more valuable, or they are a large piece of work (not estimable or small) then it would make sense to do the second example. That said, you would not do your second examples if all the searches could be delivered in a small chunk of work.

A good size for a user story in my opinion is about 3 days. Regardless, the common logic is a good user story should fit inside your iteration length, and preferably within half your iteration length.

The other thing to consider is the testable aspect, it is good to set some acceptance criteria that defines the definition of done. That is usually noted on the back of the card.

This is a starting point, but as always the answer it is “it depends”.

Finally, a good reference book around this topic is User Stories Applied by Mike Cohn (http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685)

YOW! Nights: Extracting Gold from Legacy Code

/ Craig Smith / Leave a comment

YOW! 2011Last month, Dave Thomas came to Brisbane for YOW! Nights to deliver his always insightful and entertaining presentation entitled “Mature Legacy Seeking Sexy New Technology for Fun and Profit: Extracting Gold from Legacy Code”. It’s been a pleasure to work with Dave on the last couple of Agile Australia conferences and I always try to make sure I catch his presentations when he is in town.

The following are my notes from the session:

  • a common complaint is that my boss does not let me do anything neat – legacy is a challenge
  • go where there is a big need rather than wherever everybody is – solve a problem that is important to them in a clever way
  • legacy code is code that has no tests
  • only if you have a product that matters you will have legacy – you can make bloatware even in new systems
  • legacy – the big ball of mud – OO is one of the biggest creators of technical debt
  • developers are the source of legacy debt – the developer solution is we can always rewrite it in my language – most rewrites fail
  • outsourcing often works short term – but you lose your business knowledge and you realise your requirements stink
  • vendor solution – start with a technology you don’t need
  • agile solution – just refactor it, there are no tools or practices that can fix millions of lines of code, it will take forever
  • need to figure out what the legacy is about – get the metaphor and a picture – write stories and put them on a wall, invest in getting the legacy programmers to sit down and talk about it
  • most companies are living on their legacy – new products are not paying the way
  • pair legacy and non-legacy developers to tackle the problem
  • use modern IDE, use modern SCM, new continuous build infrastructure is cheap, need fewer developers if your whole world is in memory
  • when everybody is using agile, how can it be the best practice – it is the only practice
  • prove your way through the old systems – there are very few greenfield projects
  • do TDD using live transaction roll back
  • automate from the data definition not screen scrape
  • people only do innovation when they are screwed – agile is predictability and quality not productivity
  • rewrite the contracts so that vendors can only install if they have automated acceptance tests – acceptance tests are the only way of putting two distinct processes together
  • big resource contracts should be split because the quality of resources are usually spilt in half – give it to local resources who have the talent
  • an agile coach is “an unemployed Smalltalk programmer”
  • think outside of the box – use spreadsheets to load data to the cloud
  • simple innovation in a difficult problem gets you a lot of respect – don’t ask your boss if you should write some Prolog to solve a problem
  • look where the customers are spending money – it is usually in legacy
  • lots of great opportunities to make a difference to hold your nose with the legacy smell – find where the biggest bang for buck is quickly – need to do it in months
  • KLOCs kill – more code to maintain
  • prove new ideas and do a little bit at a time