User story splitting is an established practice on agile delivery teams. But in my experience, it’s really difficult to do well.
In this article I’ve pulled together everything I’ve learned about story splitting. It’s a long article, so you might want to make yourself a nice, hot cup of tea before you get started.
Happy New Year!
I don’t normally make New Year’s resolutions, but this year I’ve made an exception. My resolution is to get more involved in training in 2017. I do run some training courses already, and I sometimes speak at meets and conferences, but I want to do more.
There’s a problem though – formal group training relies on being able to get enough interested trainees together in the same place and at the same time to make it work, and this turns out to be somewhat tricky. It’s also relatively expensive for trainees, both in terms of financial outlay and also time spent away from work and/or home.
So I thought I’d put together something a little more flexible – a distance learning course. This allows trainees to learn at their own pace and in their own time – and it doesn’t need a critical mass of trainees to be viable – it can be done on an individual basis. It’s also significantly cheaper.
The course teaches you how to be an agile Business Analyst. It’s based around the materials on this site and also on my own experiences as an agile BA.
Here’s how it works. The course consists of 10 “lessons”. I send you the lessons one at a time. Each lesson includes a learning / research element and a hands-on exercise. You do the learning / research part, then you complete the exercise, send it to me and I provide feedback. I will generally give feedback by email but we can arrange a video chat if you prefer.
I’ve just launched the course and I’m offering it at an introductory price of £400 (GBP) for the first intake of trainees, with an option to pay £40 initially for a single lesson, plus a full money back guarantee if the course doesn’t work for you.
For more details, or to sign up, see the Distance Learning page.
PS Sorry for the unavoidably “spammy” nature of this article – it was the only way to announce the new course. Normal service will be resumed henceforth, so if you’re a subscriber please don’t unsubscribe!
If anyone is interested I’ll be talking at Agile Yorkshire on 8th March – tickets are free and available now.
The talk is loosely based on the article Agile By Stealth. I’ll post the slides up here after the event.
POST EVENT UPDATE: Thanks to everyone who came and listened patiently to my ramblings. If anyone is interested the slides are available here:
Agile Yorkshire – 08-03-2016 – Tony Heap – Agile By Stealth A Step By Step Guide v2
One thing I’ve noticed about agile is that it’s difficult to really understand it unless you’ve actually done it. This makes it tricky to sell agile – especially to people who are used to a plan-driven (waterfall) approach. In other words pretty much everyone who hasn’t already gone agile.
In my experience, agile delivery is just too different from waterfall for some folk to jump in head first. It is, however, possible to take people on a journey from waterfall towards agile delivery that doesn’t involve too much of a leap of faith. In this article I’m going to describe a strategy that I’ve used a few times with some success.
[Warning – this article includes a sales pitch. You have been warned :)]
It’s been an exciting few months here at Its All Design Towers. I met up with a couple of training companies at BA2014 last September and I’ve been working with one of them – Business Analyst Solutions – to develop a training course that focuses specifically on how to be a business analyst on an agile project.
I gave a talk at Agile Yorkshire this evening – on the general theme of “how to maximise the amount of work not done”. Here’s what I covered:
- There’s no such thing as a requirement (so always challenge)
- The importance of prioritization (especially trimming the tail of the 80:20 curve)
- Feature splitting (including de-prioritizing the low value bits)
- Options Engineering (including the cheap option and the “do nothing” option)
For anyone that’s interested, here’s a copy of the slides:
Thanks to everyone who attended and especially to Matt for the pint!
This article describes Phase 3 of the Business Analyst Designer Method – Design.
This article describes a Visio stencil I have created to help BAs produce “sketches” in Visio. The BA Sketchbook stencil for Visio contains various shapes (symbols/icons) and connectors with a hand-drawn style that can be incorporated into all sorts of diagrams – such as business process diagrams, flowcharts or boxes-and-arrows diagrams. it has been reported that the resulting diagrams are well-received – especially by non-technical business people, who can sometimes feel intimidated by more formal diagrams.
On software development projects, requirements prioritization is a well-established practice, and there is a wealth of information, both in books and on the Internet, describing the various techniques you can use to do it.
But in my experience, there are two key points that nobody ever seems to emphasize enough:
- Prioritization is really important
- Prioritization is really difficult
In this article I’m going to explain why I think this is the case, and why we therefore need to be absolutely ruthless about prioritization if we want our projects to succeed.
I’m hearing of more and more agile teams using Behaviour Driven Development (BDD) as a way to specify the acceptance criteria for user stories. I hadn’t realised how widespread it was getting until I attended two separate talks on it at BA2014 this week (in particular, at the BBC and Aviva).
With each new technique comes a learning curve, both for individuals and for the industry as a whole. The technique matures as people work out how best to apply it.
But there’s good news for anyone learning to use BDD. The technique is already mature, and there’s a body of knowledge out there on how to write BDD scenarios. It’s just that people weren’t calling them BDD scenarios. They were calling them Use Cases.