Lesson #2 – The high-level concept

During Lesson #2 of the course I will try to formulate the high level concept of the product.

I have the idea for the product. In the next step, I try to present few ways of figuring out the big picture of the concept.

Firstly, let’s go one step back. There could’ve been tons of other blog posts that I could write covering the subject of an idea of the product. I could write for a long time on all the user research that needs to be done, all the stakeholder analysis that is missing, mainly – all the market research that we would do in real life to prove that what we’re doing makes sense. I will not do that for now for one simple reason. I design this course to show the big picture of the business analysis. I prefer to go through all the aspects of real analysis presenting few techniques that are helpful first. I hope to create a BA toolbox, not a scientific thesis.

The big story

So, to the point. The subject is “the big story”. Having the idea forged already, I should be focusing on what my product is going to do. In my life as a Business Analyst at a software house, I am often involved in projects from the very start – the pre-sale. Usually, I sit at my desk, being bombarded with tons of documents in different shape and form that somehow detail what customer wants us to do. I see RFPs (Request for Proposal), RFIs (Request for Information), specification documents, requirement lists, etc. being provided to you by your clients, account managers, bosses, and many other people with whom I interact. I don’t have to mention that all these documents are different from each other, even though there are many common elements. And I need to analyze this and come up with something useful, give some feedback, provide some initial analysis. What I do at this point is sketching the big picture.

Jeff Patton encourages us to “Tell our user stories” (User Story Mapping: Discover the Whole Story):

OK, let’s imagine the future. Let’s assume for a minute this product is live and let’s talk about a day in the life of someone who uses it and start telling the story. First, they would do this, and then this, and so on and so on.

Make a note of those user activities (put it on sticky notes, input it into a sticky notes software or any mind mapping, story mapping tool available out there) as this becomes the very basic description of application you will try to build. At this moment think big – it’s your high-level user benefit that is analyzed here. Don’t go into many details yet.

A word about The Customer Journey

Let’s broaden the whole subject and let’s have a look at what modern businesses are doing in the area of service design. The sexy concept nowadays is building the Customer Journey Maps, and one of the first things required to make one is nothing else that finding out what motivates the users, what are their goals. Google for some templates, there’s plenty of this stuff online.

Building the goals layer is more or less the same concept. However, this example illustrates that we must look broader – not only about the actual software functionality but also everything that is going on outside of the software.

User Stories, Epics, Themes, Modules

The primary flow of activities that you just sketched needs to go into the product backlog. How do our activities translate into the user story, epic, theme or module of the application? The answer is – it depends:
– User story – good user story undoubtedly has a who, what, why statement. Since you have built your activities analyzing your users, you probably have all 3 of the “W”. Are your activities user stories then? They might be, however, since we have focused on the big picture, most of the agile development teams are going to tell you that they are too big and you will need to split them.
– Epic – well, epic is a big user story, look at Atlassian documentation:

An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic.

So at first glance, the activities are most likely the epics. However, there is a controversy around the usage of the word “epic”. Jeff Patton has an interesting point. So let’s have a look at the theme.
– Theme – perhaps our activities could be “themes” in our product backlog? Since the theme is a collection of user stories (so the term that is more lightweight than an epic), I would say that by doing your activities flow you also worked out the themes of the product backlog you’re building.

– Module – in the end, we are developing the software. I have created many product backlogs in my life, and I can say with lots of confidence that on the level of building the activities we can figure out how many different modules the application will have in the future. One of the Domain Driven Design (DDD) principle is placing the project’s primary focus on the core domain and domain logic (Wikipedia), which is what we just started to build exactly.

Building the activities flow

I will now go back to my team management software and try to construct the activities flow. From the elevator pitch I have created the other day I can clearly list my user roles:
– The Coach;
– The Player;
– The Manager;
– The Supporter.
Now I think about the very first thing that these users will do in my application. I am telling the story.
The first activity is probably registration. It’s good to think about the “end in mind” of each activity. After the user registered, he can start using the application. From the software perspective, we are storing this user’s record in the database, user store or whatever else is going to be developed (we don’t know yet). I am using stormboard.com to document the activities map. However, you can do this in any software or preferably stick it on a wall somewhere in your “war room.”

picture1

The next piece of my story is the creation of the team. So the user would add a team, give it a name, define other metadata, probably upload some logo, etc. At this moment I might think about who exactly is going to do that – and the very basic use case is the coach. Later I might think about other user roles who will be able to do that. At this moment I could think broader, since creating a team is an aspect of team management. Team management will also be modifying team’s metadata, or even removing the team (sometimes it is worth to think “CRUD” – Create Read Update Delete operations for the team). Later, the coach is going to invite the players to the team. Technically, it’s creating a one to many relations between a team and players. A single team can consist of many players. Later, the coach can set up events. Events will be games, practice, and other activities in teams day-to-day operations. Another thing the coach is doing is uploading some training materials, photos, videos, etc. in order to facilitate the communication. At this moment, I would say the coach benefits are more or less covered, we have high-level activities this person is going to do in our software. Below is how my map looks like:

picture2

Now, the player. This guy is also registering, however entering different role he will have in the system. We already have a registration on the map, so all we need to do is enter some details on the card for us not to get lost. There are several ways to do that, I will just add the WHO statement to my card, like this:

picture3

I am indicating, that we need the concept of the role while building the registration process. Since the player will not deal with team management for now (or this is not his primary flow) let’s focus on his next activity. The player would like to join the existing team. I put this activity after all coach activities with the WHO information.The player may also join an event letting his coach know that he will participate in a game or a practice session (remember, it’s for amateur teams). My player would also like to track his/her progress, perhaps rate a training session to give the feedback to the coach. Also, when it comes to rating, I figured, that the coach would also like to rate those type of events. Moreover, the coach can give feedback to a particular player – therefore my “Rate the event” card has two user roles assigned to it.
The story of the manager is somewhat similar to the one of the coach. The only specific activity I can think of right now would be managing team’s budget.
Let’s focus on the last user role I have discovered so far – the supporter. This person is interested in how the team is doing. Also, I believe it would be cool for such person to have an option to follow the team, give feedback to the players, coach, and managers in the form of event rating (we will probably restrict the supporter to only rate the games. However, this is a whole different animal – let’s leave it for now).

I will clean it a little bit, grouping few similar activities in order to make it more concise. Let’s have a look at how the map of activities now looks like:

picture4

 

One last thing, you might notice that I added some color-coding to my map. For now, the map only consists of activities. Therefore they are marked yellow. It is a good practice to maintain your color coding though your work with the map, and later in the development stages. This just makes things more transparent.

Things to remember

After building the first draft of your activities I need to remember the following:
– Nothing’s carved in stone yet (and never will be)- in the future if I decide that I am missing some activity, the sticky note concept that I’ve chosen allows me to add more of them.
– Additional user roles – Most likely there are more types of users here. I need to remember that I didn’t discover them all yet and if they arise, I need to walk the map left to right so that new activities might be added.
– I need to test my map – I need to make sure that the map is telling the story – it’s simple – since the map is now only a one level flow diagram.

Reference:

Leave a comment