I love this approach to splitting up user story value by considering vertical slices through the technical solution.
Iterative and incremental development is a tricky art to master. Delivering very small increments of value takes some practice. With iterative development we must be happy to frequently revisit areas of the system that we are building as we learn more about them, which is quite different from the traditional approach (broad and shallow engineering versus narrow and deep).
This is where I believe the Agile Manifesto authors were coming from when they spoke about “Simplicity, the art of maximising the amount of work not done“. Implementing the simplest technical solution in order to deliver value quickly. It does not necessarily constitute the final solution, and it certainly does not mean “quick and dirty”. We still need code quality (unit/integration/acceptance tests), and the goal is to have a usable system. Something we ourselves would be happy to use and would be able to provide feedback on.
But for an individual user story we are simply trying to meet the goal of that story in the quickest and simplest way possible while providing an acceptable technical solution to meet that purpose. If the code is simple and maintainable we can easily build upon it if required, and the required architecture will evolve as we both iterate and increment.
So we want stories as small as possible (no more than a couple of days of work) and with the simplest acceptable solution under the covers. A good way of looking at it is “what’s the minimum amount of code I need to write to pass the acceptance tests?” (this approach of course leads naturally into the worlds of TDD and BDD, which I encourage you to read more about).
Working this way enables us to get early feedback on the feature and decide whether to invest more effort (via more stories) for that feature, thus allowing the flexibility for the product owner to prioritise a different area of the system if (s)he so wishes.
Some further reading about splitting user stories:
Have a great weekend everyone. Perhaps consider making the goal of your Sprint Planning meeting on Monday to split your stories down even smaller using some of the excellent techniques available. The benefits are numerous.
Good article Neil.
How do you handle dependencies between stories? For example we recently had a problem (writing an education app) where we wanted to allow teachers to create classes (i.e. named collections of students). We had two stories: “As a Teacher I want to be able to create a student belonging to my school” and “As a Teacher I want to specify the students in my class” (or something similar). Obviously adding students into the system has next to no business value without the ability to manage which students are in which classes. But you also can’t do much until you have some students in the system to manage.
Should we have broken the stories down differently, or are dependencies acceptable and just dictate the order stories should be approached in?
Will,
Thank you for all your comments and observations.
While your backlog had only two stories, the question you raise here actually highlights one of the (many) problems people encounter with a larger product backlog. If the backlog has more than 20 or so stories on it the likelihood is that too much detail is being considered. What we end up with is a big list with many dependencies, causing us to do things in a particular order. This of course greatly restricts our adaptability as it forces us down an implementation path. The PO ought to be able to take the bottom item from the backlog and move it to the top.
The problem of dependencies should only arise at the technical solution level. If there are dependencies in the user stories themselves then there is a good chance you can remove them by phrasing the stories in a different way.
You’re right about the “add student” story. It adds no value on its own, and this is partly because the story is very system-centric. “Creating a student” doesn’t mean anything outside of the context of using an app. The idea of a user story is that it should represent a need or a goal that may or may not be met with software. “As a teacher I want to know which new students are in my school”, “As a teacher I want to be able to assign new students to my classes”.
An example I always use is “As an adventurer I want to be able to cross this river”. If we make an assumption that we need to build a bridge then we start writing stories like “As a bridge-crosser I want the bridge to be safe” and “As a bridge-crosser I want the bridge to be comfortable under foot”. But the solution to the original story could be to build a bridge, build a boat or even to teach the person to swim! (the latter two would then serve their need to be able to cross other rivers).
In summary, try and restrict dependencies in your stories to the Sprint level, at the point when stories are broken down nice and small. Your “add student” story is perfectly acceptable as a Sprint story if it’s a nice small implementation piece. Coupled with the other story you have a nice little “feature” with which to gain feedback.
Pingback: #NoEstimates Part 1: Doing Scrum without estimates | neilkillick.com