John Irving, whose A Prayer for Owen Meany would probably be my choice for greatest American novel of the 20th century, swears he knows the last sentence of every book he’s written before he starts writing.
The book works better if I know everything I can about the ending. Not just what happens, but how it happens and what the language is; not just the last sentence, but enough of the sentences surrounding that last sentence to know what the tone of voice is. I imagined it as something almost musical. Then you are writing toward something; you know the sound of your voice at the end of the story.
So, knowing what the end makes it easier to get there.
Similarly, one of the basic principles of building any piece of software is understanding what done means. If you don’t have a clear idea of where you want to get to, how are you ever going to know when you’ve arrived? Unfortunately, this doesn’t happen very often. As Alan Cooper writes on page 42:
…most software products don’t have a description, instead all they have is a shopping list of features. A shopping bag filled with flour, sugar, milk and eggs is not the same thing as a cake.
So, before you start your project you better have an idea of whether you want a cake, or cookies. (Whose kidding who really? Can you put a slice of cake in your pocket when you go out for a walk? But I digress…)
Describe Your Project
We ended our last post on this topic with a note about the importance of focusing on the customer journey. This is true when you’re thinking about taking on a Salesforce fix, even if your customer is your internal team only. What you want to build is driven by both internal and external needs.
Describing it clearly means focusing on results, or outputs, or deliverables–you can use a few different terms. The main point though is not to focus on the steps your project takes, but on the end game. When a Sales deal is closed, Customer Onboarding should happen automatically is a pretty good simple description. When an Opportunity is Closed-Won an Onboarding Case is Created isn’t right now: that’s more of a requirement, and we’re not there yet.
To use Irving’s quote as an example, that first example here is an outline of where we want our novel to end–knowing this up front makes the story of how we get there (the requirements) easier to write. We’re building toward something.
This may seem obvious and yet it doesn’t happen as often as it should. So many projects start without even basic design or a project charter. This is particularly true for small projects, but the smaller size doesn’t mean it’s a good idea to skip these steps: it just means the impact is less.
So, write a description, get buy in and circulate it.
Wait–How Does This Translate to Agile?
Inmates is not an Agile book. It was published in 1998, and the Agile Manifesto was published in 2001. Still, it comes from the same cultural viewpoint and it shouldn’t be a surprise that some of its themes are similar.
So, how does this apply if you’re running your project in an Agile fashion?
Agile Does Not Mean “No Requirements”
I worked on a project once with a large consulting firm and the project manager kept repeating “Agile means no requirements.”
I’m not sure where this idea has ever come from, because it couldn’t be more wrong. Agile needs requirements, it just doesn’t ask you to write an 800 page requirements document before starting to build your project. Requirements can be shorter and more concise but they should still exist, and you should have them relatively well defined before you start building but you don’t have to have them done end to end.
Break your project into discreet chunks and define done for each one. You can finish Leads before you finish Accounts, for example. You probably can’t create Contracts without having the Sales Process (including Opportunities) done though. Define requirements for each of those–even if they start high level.
Epics
So are these requirements Epics? They could be, yes. Epics are a fundamental organizing principle of Agile and you could probably use these requirements to create them. I’ve also seen a lot of Agile projects succeed without actually using Epics. Whether they exist formally or not is a decision you should consciously make though.
Sprint Dates are Irrelevant
When you plan your Agile project you generally decide how long sprints are. Most times I hear two weeks which is too short, but people keep doing it. Sometimes I hear three–me, I tend to plan on four weeks (which really means “a month”) but with an interim minor release possible. There’s two simple reasons I like four weeks on Salesforce projects: it makes it really easy for everyone to know where we are in a sprint, and if you’re working with a full copy sandbox you can only refresh it every 30 days. So, a month works.
But here’s the thing: just because you reach the end date of your sprint doesn’t mean it’s done. If you’re building a house you plan a schedule but when you get to the planned end date you don’t just close up and stop: what if the roof isn’t done? The electrical wiring? You probably can’t move in without a city inspection either–this house isn’t going to pass.
On your software project, hopefully most of your tickets are done at the planned end sprint date but probably some aren’t. You’ve got some practical things to do before closing the sprint–move them into the next one (which is probably already full?) Drop them? Whatever you do, the goals and requirements define what’s done, not the dates you stuck on a plan.
User Stories and Done
User stories and Sprints are the fundamental organizing units of an Agile project, and these can’t be skipped. Atlassian has an excellent guide to user stories here that’s worth reading in full but the summary is a good place to start:
A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.
There’s a couple of key points here:
- They are written from the perspective of the end user, not the developer
- They are informal and should focus on value
- The describe a feature, not a bunch of features
We often write user stories in the format of “As a…I want to…so that…” but it’s important to remember this is just a guide, not a rule. If you’re just trying to get a single field added, this may not be helpful (though you should be clear about who was Read Only access, since Salesforce defaults to Read/Write.)
In practice, we fill a sprint with User Stories and developers work with them to build our solution. This means we sometimes add additional information focused on guiding devleopers (e.g. Technical Requirements or Expected Test Results) to the user story. This should, if you ask me, be done with the developers but sometimes that doesn’t happen. You be you, but remember the team succeeds or fails as a team.
So how does this all relate to understanding what done means? Simple–while you’re overall description doesn’t have to be 100% complete, every user story needs to have a clear definition or it can’t be delivered. As a Sales User I want to be able to write reports isn’t a very good user story–it’s a feature. As a Sales User, I want a report that shows me the total value of my open sales deals by month is something that can be delivered. We know what done means.
Concise and clear is the goal here. Use bullet points to help. Watch out for words like “if,” “and,” “or”)–too many of these and you might be better of splitting your user story into smaller pieces. Some user stories will be bigger than others, but the goal is simplicity–it should be easy to tell when it’s been built correctly.
Knowing Done Help Us Define What We’re Doing
Gord Downie has a line in a great movie call One Week where he comments on the protagonist’s motorcycle trip and says “So you’ve got direction but not destination.”
This is a fantastic plan for a motorcycle trip–trust me on this one. It’s not a good plan for your Salesforce project. It just leads to confusion and uncertainty about what’s happening. Knowing what done is means you get to pause for a minute, take a breath and move onto building your next great thing.
A Note About John Irving
John Irving, by the way, is a Canadian citizen now, having been married to a Toronto native for quite some time he took the oath on December 10, 2019–just before the COVID pandemic. It makes me proud to think of him as one of us, and I’m happy to know what Owen Meany can also be ranked amongst the greatest works of Canadian literature. Those borders are boundless and arbitrary anyway.