Mini-experiments are a key aspect of the Lean Startup movement, so I like the idea of user stories as experiments.
Continue reading
Tag Archives: scope and requirements
Quality is a choice: the case of the Next Generation Apps
Over the last year I’ve had the privilege of overseeing the development of the next generation of mobile apps (iOS and Android) for the major commercial radio brands in the UK. The most amazing thing about this experience was the priorities – UX&D was #1 priority – something I’ve never had before.
Continue reading
35 person-years worth of prototype is a fantastic spec
I once invested 35 person-years worth of effort on prototyping. From my perspective this was time and money well invested. By the end of that time we knew, really knew, what problems our customers were facing and how to solve them.
Continue reading
Scope Creep v Flexible Scope – Undisciplined v Agile
Bart asked “What do I do when agile is abused as an excuse for scope creep?” with the sub-text “You’re agile so you’re flexible, no?”. I say point out the difference between scope creep and flexible scope. Agile makes changing scope a zero sum game – that gives flexibility without the creepiness.
Continue reading
Don’t use the Formal User Story Format for Minor Modifications
Kim Daubney asked what to do when the story isn’t a new requirement but a UI change. Kim wanted to know if the “as a, i want, so that” format is still required? Short answer is “no”.
Continue reading
Purpose Finding: Only solve problems you need to
Brian Williamson has commented that although “problem-solving is important and good when you are stuck. I’m convinced we are in need of some more purpose finding.” I agree and finding purpose manifests in several places in my approach.
Continue reading
How to spot a Product Owner’s Pet Requirements
Everybody has pet requirements and product owners, being human, are no different. Unfortunately pet requirements are a real risk to software projects. We should all resist these pet requirements and do everything possible to kill them off ASAP and avoid building them. So how do you spot pet requirements
Continue reading
Who is Specification by Example for? Everybody!
I was talking to Pedro Santos on the train the other day. Pedro is my technical lead, an expert in his field and a keen advocate of automated testing and software craftsmanship in general. We were talking about Gherkin and Pedro was saying he doesn’t see Gherkin tests adding value because it doesn’t help him as a developer. Of course I disagree. The way I look at it is the Gherkin tests are not for the developers. The Gherkin tests are for the organisation – they are for everybody.
Continue reading
It is ALL Number One Priority / It is ALL Must Have. Not true!
If the customer claims everything on the product backlog is top priority, and by implication must have, then you’ve a bit of an education job ahead of you. You have to get the customer to the point where only one thing is top priority and even “must haves” are sorted into a priority order. There is a good chance some of those “must haves” turn into “would like to have” and in time disappear.
Continue reading
Solution Convergence: Marrying Business, User Experience and Technical Input
My product owner was upset when I told her she couldn’t have the widget that she had agreed with the User Experience (UX) Designer. The problem was the design was not technically feasible. To get a great solution to meet the business requirements three parties – business, user experience and technical – must agree on the approach. That negotiation is what I call “Solution Convergence”.
Continue reading