Hi! My name is Gem, and I’m one of the test team here at CTI.
Today I want to talk to you about requirements, and how we help gather and refine them during planning. We do this primarily through workshops, held here at CTI’s offices. Workshops are where you’ll meet the members of your project team, get familiar with our project processes, and start getting into the nitty gritty of project planning. But how do we refine your requirements into individual features that we can deliver? Well, let me be your guide through this process.
Workshops are usually all day affairs here at CTI’s offices, and are split into multiple parts:
Meet the team
First, you’ll get to meet the CTI Digital team that will be working on your project; who we are, and what we do. You will have an opportunity to introduce yourselves and summarise your responsibilities in the company and on the project.
We will ask for a product owner or point of contact for the company; this person then becomes a member of the project team with us, and will be kept upto date on progress of the project.
Meet the business
Before we get into the details of the project, we’ll want to improve our understanding of the context of your business. We’ll want to know who the project will be targeting, what their goals are and what your goals are.
If you’ve got an existing site, we’ll review that; what works, what doesn’t and how you’ve used it to get to your goals so far.
We’ll also introduce you to our business; how we work and the tools we use in projects. As project team members, you’ll have access to some of these tools so you’ll have visibility of the project at any point, including seeing any tasks assigned to you for action, seeing feedback and generally keeping up to date on how things are moving along.
Meet the requirements
When you attend the discovery workshop, you may have ideas already for what you want, but we’ll want to talk about the underlying reasons and how you got to your ideas. This not only gives us context, but also shows us what you think is important, and allows us to bring our expertise and experience to not only provide the technical implementation but also offer ideas on features and ways to deliver functionality.
If you don’t have concrete ideas, that’s great too. We can draw on the expertise of our various teams in either case to help hash out requirements and offer ideas and solutions.
Meet the tester
As a member of the QA team, I love workshops. You may be surprised to see me there, but workshops are really useful for me.
I’ll explain.
My testing goes far beyond ‘does this work?’ It’s ‘does this work, and then, is this right?’ It’s pointless having a functional piece of development if it doesn’t meet your needs. It’s part of my job to make sure that not only we gather feature requirements but also the underlying goals and ideas for the features so we can deliver something that helps you meet your goals.
For example:
You might say:
- I want a homepage banner, with a video.
We would ask:
- Would you want the banner to be a static image on mobile devices?
- Or maybe not even there at all? If mobile users don’t need to see it, do desktop users?
- What about a fallback image for users who are using devices that don’t support the videos you’re using?
- Depending on the accessibility levels you want to reach, I may talk about having controls on the video for play and pause.
In addition to testing the features produced later in the process, I’ll be testing the requirements in the workshop, and offering scenarios and ideas and seeing how the requirements change or meet these scenarios. Workshops shorten the feedback loop; we'll share our assumptions based on what you’ve said and you can tell us if we’re right or not.
These workshops provide the foundations of the project. After the workshop, we’ll go away as a team and come up with a list of features, start designing and think of all those questions we didn’t think of at the time. Most projects here have two workshops. The second workshop will be refining the features even more; showing designs and asking more questions, so we can nail down user stories. At the end of it, we’ll have a list of features in your project backlog and we’ll be planning them out.
Before we start building we’ll hand you over a set of designs and a list of features for the first ‘sprint’ of work, for you to sign off. Agile is inherently flexible. Things that you may have wanted during planning may become less of a priority as the project moves on, or vice versa. This is why we focus on context and culture during planning as well as features. We want to make sure that, regardless of the features we implement, we produce something that fits the needs of your organisation, its culture, and its context, whether it's for the coolest kids, or servicing one of the largest cities in the world.
