At its core, the Activity Kit is a tool which focuses on collaboration and design. It was built by a team, for teams, and has the concept of community woven throughout. That being said, the kit was originally made for the Codebots team, and is therefore biased to the way that we work. As we have What is a Way of Working?, every team and organisation has their own way of working, and therefore would have their own approach to the scoping process, meaning they would need their own activities.
We highly encourage this sort of initiative, and ask only that you share your work with us so we can see what has been done, because we delight in sharing with our community and love to see what they can produce. Below, we have broken down all the considerations that go into making an activity, and then how to go about documenting it:
Planning the activity
What is the desired outcome?
The first thing you should ask yourself is: “What is the main goal of this activity”? What problem are you trying to solve? Once you have that realised, the rest of the information will fall out of it. It is important that there is a single, specific goal in mind when you are running an activity. Too many goals, and the team ends up confused and unproductive. No goals, and nothing substantial happens. The outcome may be that an artefact is created, like a list of user stories or a problem statement, or it may be a clarification or learning about the product, like the priority of the user stories, or a list of feedback from existing users.
What stage should this belong to?
Knowing your goal will help you identify which stage the activity would belong to. Most of the stages are fairly self explanatory, and provided there is a single outcome for the activity, very easy to place. Is the purpose of the activity to understand more about the project? Then it would go in the Understand phase. Are you trying to learn more about how people would go about using the product or solve the problem for themselves? Then you are Observing. Are you trying to think of potential solutions or come up with ideas? It belongs in the Ideate phase. Are you creating prototypes or other ways of validating a potential solution? Then you are Prototyping.
Who should be involved?
Once you have established what you want to achieve, the next question to ask is “Who in the team can help you to achieve it?”. The Codebots’ Activity Kit participants are drawn from the following list, though you may identify additional players who may need to be involved:
- Designer
- Techie (developers and testers)
- Product Owner
- Stakeholders
- Domain Expert (can be brought in to help consult on a particular piece of knowledge)
- Users (Potential and existing people who use the system)
- Facilitator (someone external to the project who can help run the activity so all team members can be fully involved)
Now, “Who should be involved?” is not the same question as “Who needs to hear the results?”. Sometimes, there are cases where a team member needs to be involved in a discussion about the outcome, but they have nothing to contribute to the actual activity. When making your list of participants, keep this distinction in mind.
That being said, it is normally important to a project’s success that the team understands why a decision is made. If it would be more beneficial to have the whole team participate so they understand the process, then encourage it to happen. However, the reality often is that the whole team is not available to sit down together for every activity. Instead, we would encourage you to report on your findings when you do get the opportunity, and do your best to help everyone understand the process you went through.
If you can manage it though, try to get as many team members involved in as many activities as possible, even if it seems like they don’t need to be there. The last thing you want to encourage is the mindset of “you don’t need me, that is the x’s role”. We have found that all team members can become engaged within an activity, even if they feel like they aren’t creative, or can’t be a techie. Everyone has value to offer, and you never know where gold is going to be found. It will also help the whole team be more motivated to see the product through to success.
What are the steps?
The first time you try an activity, think of it like an experiment. You should go into it with a hypothesis of what you expect to happen, test what works and what doesn’t, and make notes about everything that happens. Part of this includes documenting every step that is taken, whether they work or not (we would suggest recording your first few attempts, so you can be fully involved in the activity rather than distracted with note taking).
When you feel like you have a pretty stable method, you can write down the instructions. Make note of any points in the method where the team might run into difficulties or get confused. What can be most beneficial though, is photos and videos of the team doing it. Particularly with the more fiddly tasks, it can be hard to articulate what needs to be done via text. Videos and photos are the easiest way of communicating what needs to be done (but don’t rely on it, make sure it is written up as well!).
Other considerations
There are a few other, more minor points, which should be included in your documentation:
| Title | Description |
|---|---|
| Time | How long the activity will take (usually in hours i.e. 1-2 hours) |
| Description | Theory behind the activity, why it is helpful, more advanced instructions, things you need to know before you start etc. |
If you require any digital materials like documents to fill out or card templates, make sure you make them easily accessible to anyone who could be reading the activity.
Writing it up
The most important part of creating a new activity is making sure it is written down. You don’t want your creative work to be forgotten. What you want to do is make sure that it is documented in a place where not only your internal team, but any external clients, may be able to access it. We have found that it can be quite valuable to send activities to our clients before a meeting, so that they know what we are trying to achieve out of each session.
Your activity should look like the following structure:
- Name
- Summary (Desired Outcome)
- Recommended Stage
- Suggested Time
- Participants
- How to run (Sentence summary, then quick step-by-step instructions)
- Description (Go into the theory of why it is important or how it can help)
- Method (more in-depth details for steps where pictures might help)
As you use your activity, keep in mind that it is not set in stone and can evolve as people use it and become familiar with it. What is important is that you document any changes or variations you discover, everyone can learn from it.
Teaching it to your team
If you work with other people who use your activity kit, make sure you share with them what you have created. We find the most effective way to teach and encourage the use of a new activity, is to run your team through it themselves using a fake project, with you acting as a facilitator. It is an excellent way to get feedback and improvements, and nothing teaches quite like submersing yourself in it.
Written by Tessa Mylonas
Head of Support and Education
If Tessa isn’t busy answering support questions or educating you about the Codebots products, she is typically found putting together flat-pack furniture, playing with her chocolate Labradors or hoarding houseplants.
