I don’t know if Problem Stories have been ‘invented’ by the Agile community or not yet, but given the popularity of Lean Startup and Agile finally figuring out most organizations want to implement Agile to solve business problems, how about we start using Problem Stories instead of User Stories?
Job Stories already exist, and I think I read about the term ‘hypothesis driven development‘ a few times, but as far as I can tell, no one has ‘invented’ Problem Stories.
I hear-by proclaim intellectual property rights over Problem Stories!
If you haven’t figured out that I’m being flippant by now, well, I am so relax!
Problems with User Stories
There are plenty of posts out there about what’s wrong with user stories and I am too lazy to find them. Google it. They are good for teams that are new to Agile, but these teams should outgrow using them in favour of other techniques like BDD, ATDD, FDD, FTD and any other variation of <snappy name> + “DD”. Two of the main problems I’ve seen are:
- assume there is a 1 to 1 relationship between user stories and requirements.
- still focuses teams on requirements, not outcomes…even though the <so I can> clause of the user story *should* speak to the business reason behind the story
Goodness in Problem Stories
Problem Stories can explicitly keep teams in the problem space by phrasing the story differently. The input to creating problem stories would come from the people who are in direct contact with customers and stakeholders. That could include your helpdesk, sales people, and product owners (if they are working directly with customers).
It shouldn’t come as a surprise that your helpdesk people know your product the best and they know what pisses off customers. If you ARE a customer-facing organization, listen to what those folks have to say. It’s unfortunate I’ve seen too many organizations consider support to be a low-paid function to help customers figure out how to use shitty software.
The Anatomy of a Problem Story
Our customers are having <this problem> because they can’t <use some shitty feature> that is supposed to help them <do this job>
Validation Criteria Instead of Acceptance Criteria
<some qualified data> of our customers call about this problem every <time period>
An Example
Our customers are have having a problem uploading files because they can’t find the upload screen that is supposed to help them attach a PDF of job posting to a job ad.
30% of our support calls are about this problem every week.
It’s all about the process
During Backlog Grooming or whichever meeting you use to prioritize work, invite a person from support, sales etc to bring their Problem Stories. Have the team provide options to solve it. Sometimes it IS easier to leave the problem with support in the short term. Once I worked with a company that was using a really old text editor that sucked. Replacing it would have been a 4 month project so we decided to leave it. I’m sure they’ve replaced it by now though!
We all *know* we should be focused on using Agile to solve customer and business problems, but we still try and use features (solution focus) to solve them versus staying in the problem space a little longer.