Teeing up Sprint Planning

This is a continuation of a series (#2) on how I handle clients and other stakeholders that are non-technical. You can see part one here that explains more on this series.

Since we have the first conversation out of the way, now we need to move to creating some early sprints, at least at a high level (epics basically). I tend to create a bunch of items based on the conversation we had that I detailed in the previous post. I try to hit on some of their unique features to show I listened and add in ones that are obvious for the type of app, like Login, NewsFeed, Profile, Liking/sharing for social media apps or Login (2 different users), payment processing, proximity alerts for apps like Uber, etc...

I ended up creating a brand new SaaS for it (the Mercury Platform), but originally I used Trello and even google sheets to help the client understand. I would then go down the item list and add user stories. I would fill in the blanks to these 3 statements

1. As a _______
2. I want to ________
3. in order to _______

This is the standard user story and from here, you could add comments and let the client see a pretty simple way to understand the user stories and the items they describe. This also allows them to get into the agile mindset of moving sprint by sprint towards MVP and beyond. From these items, right before the first Sprint Planning meeting (to them just a call), I take an item or two (normally login or some other thing that will be noticeably working after the sprint. This is done to foster the trusting relationship early in the process) and separate it from the rest as the "next up" sprint.

This is also where I make high level general quotes for each item. They are explained to be high to the client and based on previous experience. I leave 0 for any item that is unique and would require development to voice and opinion. We don't like involving development because of the intricacies of our individual process at Blast Off Apps, if you employ the developers directly, they can help clear up any ambiguity here and get better quotes for the client.

After this is complete and we have some idea of the work involved, it is time for me to jump on a call with the client. This meeting normally takes ~1 hour and we strive to keep it at that level to constrain extraneous conversations.

The first sprint planning meeting is simple. I disucss what we're after, the MVP and beyond and how we get there through 2 week sprints. The way it tends to work out (every app is a little different) is that we spend 1 week developing the functionality required and then 1 week bug squashing and error finding. During this time other sprints are planned as to start the next week of dev. directly after the previous sprint's testing week.

We need to first decide if this is native or cross platform (for apps). I have broached this subject and explained it on Slack or email prior to this meeting. I explain the difference (and the double work for native) again to make sure they have no questions and after a little discussion, they land on their answer and we move towards the first sprint.

In order to help the client learn how to be a Product Owner (the eventual goal), I start by teaching them what Acceptance criteria are. I don't directly say that to start, I just ask the simple question, "What is a yes or no question that will prove this is done as we expect". I tend to give an example from the item we are working on. Then, as they begin helping, we work through the sprint. At the end of this call is when I explain what we did, defined the acceptance criteria, and the call is pretty much finished.

In the system we use at Blast Off Apps, we are paid per sprint. Therefore, this is also where we tell them the ball is in their court. We have the items parsed through and once they pay (invoice is sent after call) we will engage development and spend the first day or two of the next sprint making sure development has all it needs to deliver. This is where I would handle everything to keep the client from being overwhelmed with technical nomenclature.

At this point, I have all the information and a pretty good relationship with the client, albeit new, so I can ask any clarifiers needed. During early sprints, ones that build infrastructure and are pretty similar to others, I use the company's artifacts to pretty much avoid any possible confusion. Algorithm sprints and other complicated things take longer, as is expected and ends up baked into quotes and the full team is more involved in discussions to start the week.

As the client pays, the sprint begins and this post ends. Stay tuned for what happens in the next steps of the process we use.