At Coshx, we have found that the best way to get a new project off to a great start is with a planning day. No matter what their background, what amount of planning they’ve already done, whether or not they’ve already had one or more false starts with bargain developers, this day always proves to be very productive for everyone involved. It helps us understand the client’s vision, introduce the client to how we work, break down the work into small pieces, and prioritize that work for maximum efficiency. By the time we’re done with the planning day, we’re ready to jump into the work, the client has a very good idea of what to expect, and the working relationship is off to a great start.

We love planning days. We know what to expect because we’ve done them many times. We also understand that our clients, who usually do not come from a technical background, don’t know what to expect and might feel somewhat apprehensive at the start. We are also aware that we tend to throw around some terms during planning days as if they’re already common knowledge, which can be frustrating and intimidating for the client. We obviously don’t want that.

My goal for this post is to explain how the planning day works and define some of those terms we tend to throw around. Most importantly, I want new clients to go into their planning day and into our entire working relationship feeling empowered to ask us to stop and explain ourselves at any time.

So, let’s assume you, the reader, are going to participate in a planning day with us soon. Please stop us and ask questions early and often! You won’t be the first or the last client to do that, and letting us know where we lost you is great feedback to help us do better next time. If you also read the rest of this post then you will have already earned extra credit when we meet on your planning day.

What happens on planning day? We meet and discuss your project. In particular, we discuss what problem you’re trying to solve and what will make your solution successful. Using various techniques, we do our best to focus the conversation on goals and reasons for those goals rather than specific solutions. This often enables us to suggest simpler, less costly, and/or more ideal solutions than you may already have in mind.

Then we gather a list of user stories, which concisely describe the who/what/why of each feature, on sticky notes. Once you feel that we’ve collected them all, your job is, with our guidance as needed, to put the user stories into the order that you want them done. If this is difficult, which it often is, then we might ask you such questions as If you could have 5 minutes with Eric Schmidt tomorrow, which of these features would you most him to see in action?, or, Does this story really need to be automated from day 1? Or could you do this manually until you have a substantial number of users?

At this point, the planning day is more or less finished. We enter the prioritized stories into an online tracking tool during the meeting or very quickly afterwards. And we get to work building your new product.

Without further ado, the following is a list of terms we may throw around during planning day. It is not meant to be complete, or entirely accurate from the perspective of any particular Agile methodology. It is simply what works well for us on new client engagements.

acceptance criteria- A clear set of conditions that must be true in order for a user story to be accepted by the client. Because user stories are somewhat abstract, they can sometimes be misinterpreted. We add acceptance criteria to stories that appear prone to misinterpretation. For example, if the user story is about creating comments, the acceptance criteria might clarify what should happen if the user tries to create a comment without logging in first.

Agile A set of guidelines for software development that leads to a better product and happier stakeholders than previous methods. The word “Agile” is heavily abused. In brief, everything we do at Coshx is consistent with Agile principles and borrows from established Agile methodologies, particularly eXtreme Programming (XP), Kanban, and Scrum.

AgileZen An online tool that helps us communicate about user stories, visualize their flow from the Backlog to In Progress to Complete to Accepted, track overall progress, etc…. There is no shortage of similar tools. This is currently the best fit for most projects we work on.

automated tests A set of tests that we write as we write the code. We know right away any time any code change makes these fail. And we don’t do anything else until they pass again.

backlog A prioritized list of user stories to be worked on next.

behavior-driven development (BDD) The practice of adding new functionality only after writing one or more automated tests that will only pass once the new functionality exists. This creates better software with a lower lifecycle cost by focusing the developers’ efforts and adding to the automated test suite. TDD happens at a lower level in the code than BDD. If you’re not a developer then it’s safe to use both terms interchangeably and assume that we are too.

definition of done A set of standards that every story on your project must meet before we would ever ask you to accept it. For instance, if your project must have a mobile-friendly user interface then the definition of done for your project might include a list of mobile device and browser combinations that every new feature must work correctly on.

demo This is a quick meeting at the end of each iteration in which we demonstrate what we accomplished since the last demo. It’s ideal to have real users in this meeting in order to get real feedback. We take notes of any new ideas that arise in the demo so they can be made into new user stories to be prioritized by the client.

do the simplest thing that can possibly work (DTSTTCPW) This is how we roll. It frees up resources for what really matters. You’ll find that on planning day and throughout our working relationship, we will suggest simplified methods of accomplishing your goals whenever possible.

github An online tool where we store your source code. We’ll set you up with an account at the very beginning of the project so you will always have access to the latest code. You won’t need to worry about it beyond that.

happy path What you experience 99% of the time when you interact with software. For example, when you try to update your profile in a web app, the happy path assumes you are already logged in. The unhappy path needs to recognize that you’re not logged in, give you the opportunity to login, and then take you back to what you were trying to do, hopefully without losing any work.

iteration A block of time on the calendar (usually 2 weeks) in which we do as much work as possible, ending with a retrospective and demo. Subsequent iterations begin immediately after the current one ends.

iteration 0 The first iteration, in which we typically attempt to clear away as much overhead as possible (project setup, etc…) and mitigate any particularly risky pieces of the plan (investigate mission-critical 3rd-party services, etc…)

Lean A structured product development process that involves formulating hypotheses about the value your product provides, validating them with low-cost experiments, adjusting to the results, repeating as necessary, and then finally building out your product when you know from experience what the market demands. This reduces wasted investment and time to market while delighting customers and creating excellent market fit. Depending on the project, it might also help you avoid having to seek outside investment.

pair programming The practice of having 2 developers work together on the same code (2 mirrored monitors, 2 keyboards, and 2 mice). It might seem counterintuitive but this increases the pace of development and the quality of the code and the product. We can provide plenty of evidence for this if you prefer not to take our word for it.

product owner The Product Owner’s role is to determine what features the product needs, prioritize the features, work with the development team to answer questions and accept completed stories, participate in the retrospective and demo, etc…. This role is almost always played by the client with guidance from us as needed.

retrospective A meeting that occurs at the end of each iteration. We get together as a team to discuss what went well, what could have gone better, and ideas to try to make the new iteration go better. This helps us to constantly improve our working relationship and team performance.

sprint Often used interchangeably with iteration. Iteration is preferred.

staging server This is where you’ll see our work in progress as we go. We’ll keep it current with our latest work so you can validate each user story as soon as we report that it’s finished. This keeps the feedback loop nice and tight in order to minimize wasteful communication delays and rework.

test-driven development (TDD) The practice of adding new functionality only after writing one or more automated tests that will only pass once the new functionality exists. This creates better software with a lower lifecycle cost by focusing the developers’ efforts and adding to the automated test suite. TDD happens at a lower level in the code than BDD. If you’re not a developer then it’s safe to use both terms interchangeably and assume that we are too.

user story An expression of something your application should do. Planning day mostly involves collecting, simplifying, and prioritizing user stories.

That’s all there is to it. I hope many future clients will read and benefit from this. Please let me know if it’s helpful.