When taking on a large project, one of the most difficult tasks a software crafter faces is breaking it down into manageable, deliverable pieces. If we want our process to be truly iterable, we will need to have some tools at our disposal to help us with this process.

Both Uncle Bob, in his book Clean Coder, as well as Kent Beck, in his book Extreme Programming Explained, lay down some great practices (as well as some amusing anecdotes) that could help guide us through some more difficult processes. I would like to specifically look at vertically sliced user stories, as well as PERT Estimation. These should be basic tools in any software crafter’s toolkit.

Before we talk about how great vertically sliced user stories are, we should probably describe their less ideal counterparts, horizontal slices. The image most associated with user story slicing is a layer cake, which I will stick with, because cake is delicious and fun to look at. Here is a layer cake.

Looks pretty good, but it would probably be easier to eat if it were sliced up. If somebody sliced this cake up horizontally and gave me only whipped cream, I would be pretty bummed. This is not far off from the idea of taking a horizontal slice from an application. You could build some back end functionality, but unless someone on the user side can do something with it, it feels a little underwhelming. Let’s look at a more concrete example.

If we think about a Django app, we would have three easily recognizable layers: Model, Template, and View. In horizontal slicing, we would only look at one at a time. If we spend our time focusing solely on one layer, it becomes difficult to deliver something useful to our end users. Even worse, what if I spend all of my time setting up back end logic and go down some weird path that is not at all what the end user wants?

The solution is to work through multiple layers to find one logical path for a user interaction? A-ha! The vertical slice! What does this look like?

Vertically Sliced User Stories

Let’s say we want a person to be able to see all of their blog posts for an awesome blog site we are creating. If I were working in horizontal slices, this might mean building everything related to blogs on the back end, then moving on to everything associated with them on the front end. This is not great if we want to have something to deliver to our end user. How do we know if the functionality is in line with what our user wants? Maybe we should narrow our scope a bit, and first focus on just displaying all of the blogs a user has.

We could create a user story that looks something like, “As a user, I would like to see all of my posts displayed in one place.” This gives us a scoped-down and attainable goal to work toward, and some acceptance criteria to know when it is ready to show to a user.

We now have something we can deliver to our end user! But how long is this going to take us? When will it be ready? And obviously this is only one piece of a larger project. How do we stay on the same page with the people who want to see results? It’s time for us to put an estimate on this story.

Estimation

Estimation seems pretty simple on the surface. Just figure out everything we need to do and figure out how long that is going to take. Easy, right? Wrong.

As most of us know, there are too many moving parts and unknowns on a given project to be able to deliver concrete commitments on stories, especially new features that haven’t been tackled before.

Estimates are a great way for us to not only give a rough timeline to our end users, but also to gauge our team's confidence on the difficulty of completing a specific task.

A great tool for tackling estimations is offered in Clean Coder: PERT Estimations.

PERT

Although there are many benefits to PERT, for me there are two major takeaways. First, it is a way to step away from an idealized world where there is only one answer to how long something could take. It forces us to think not just about the average or optimisitic situations, but also about worst-case scenarios. This can help teams uncover risks and even blockers that we'd totally miss without that explicit permission (and requirement!) to be pessimistic.

Second, it is a great way to involve our team in the decision-making process, and make sure we aren’t living in our own heads. I have personally experienced more than a few occasions where myself or a team member have made assumptions about a task that turn out to be wrong. These assumption usually only show themselves when you are asked to justify your estimates.

So how does this work?

PERT is based on three estimates: Optimistic, Realistic, and Pessimistic.

Optimistic is how long it might take to complete if we never had to go to meetings, never got blocked, and got a great night’s sleep the night before.

Realistic is our gut feeling on how long it might take. Based on our average day, how long would it take to finish this story?

Pessimistic is that worst-case scenario. Full days of meetings, we get stuck on every detail, and we’ve been awake for three days. Okay, maybe we don’t have to go that far, but this is Murphy at his worst.

Take these numbers and run them through a PERT calculator, and now we have an estimate that takes into account all three estimates, and also gives us a confidence level on that number given its standard deviation.

This alone is pretty great, but it is just one person’s estimate. A much better gauge would be to pull in our team members and have them weigh in.

Flying Fingers

A simple way to do this is with what Uncle Bob calls “Flying Fingers.” After discussing the story and its possible difficulties, the team will think of estimates individually, and then simultaneously show the points they feel appropriate with a show of fingers. Although it may seem trivial, it is very important that everyone shows their numbers at the same time. Doing this helps to avoid one loud voice from dominating estimation sessions. We have all worked with (or been) this person at some point in time. Once everyone has shown their estimates, if the results are not unanimous, the group can take an average of what is shown. This is a great way to see where everyone’s confidence lies, as well as a time to discuss any concerns if estimates vary wildly.

Conclusion

We now have a story that is deliverable to our end users upon completion, acceptance criteria for that story, and an estimate for how long the work might take. With these tools we will be able to stay on top of our work and keep delivering to keep everyone happy!