By Sheyinka Harry
We’ve all undoubtedly experienced times when issues arise during projects and within teams that could have been easily avoided. How, you might ask? Simply by asking the right questions. Having enquiring minds and openly asking questions can help uncover potential challenges and ultimately play a huge part in the generation of optimal solutions to these challenges. Looking closely at the How, Why, When, and Where of a situation is the best way to gain deeper insights and develop more innovative solutions. We are able to get clarity on user needs, product direction, reduction in ambiguity, and greater team alignment on the experience to be constructed and the work needed to get there.
In the Agile space, questions are encouraged, and there are even key Scrum ceremonies created to facilitate the teams coming together to achieve group clarity on work to be done. These ceremonies are the Daily Standup, Backlog Grooming, Sprint Planning sessions, and the Sprint Review. They provide an open floor for all members of the product development ecosystem to air their queries. It is very important to note that multiple groups of people are involved in this ecosystem to get a quality experience or product to market. There are Developers, Quality Assurance and DevOps Engineers, stakeholders, and support team members, all working together to achieve an end goal.
So why is it a rarity for questions to be asked despite having these open floors? Why are we so reluctant to come forward with any queries we may have floating around in our heads? Upon some introspection, and in speaking with a fellow Agile coach and transformation lead, Elena Astilleros, we came to the conclusion that teams either don’t know what to ask, or they don’t think they should be asking certain questions. There are also cases in which persons cannot think of pertinent questions until something goes awry and pulls an area of uncertainty into their line of sight.
Due to not knowing what to ask, we see many assumptions being made, which oftentimes result in the creation of lackluster experiences that do not meet the customer’s needs. As a means of helping teams overcome this issue, we have gradually developed some powerful Agile questions that everyone in the ecosystem should be asking themselves when defining and engaging in product development activities. We’ve outlined the importance of each question with the hope that teams can engage in more focused and fruitful conversations and leave with joint clarity and understanding.
Discussed below are some of the most powerful questions all team members should ask before and during an Agile project.
Why are we doing this?
Are you really doing your best work if you don’t know why you’re doing it? Aligning on that North Star (that is, your Product Vision Statement) is imperative for the success of any initiative – whether long or short term. This statement communicates concisely where the product hopes to go, as well as what it hopes to achieve in the long term. The product team can then use it to derive the short-term hypotheses they will be validating with target customers.
Who is this for?
Knowing the intended audience and taking the time to understand their needs is essential in refining the product to be offered. You need to define the product or service that can be offered, clearly identify the person or business you want to serve, and then tailor this product to their pain points. Different solutions can be engineered, such as if you are defining a solution for a parent as opposed to a child.
Who owns the work?
If the owner of the work isn’t clear, issues will arise. The owner is the person calling the shots or making the decisions for a particular area. There can be shared work among the team members, but there should be someone who guides and owns the full scope of work to avoid confusion as to who should make the final decisions. A typical example of having an owner for shared work is how stories are worked on in JIRA. On the teams I’ve worked with, these product backlog items are usually broken down into smaller tasks spread across front end, back end, integration, and testing. These tasks are assigned to multiple team members to do the work, but there is a single person owning the actual story. From the business end, there are some line items outside the product features that need to be accomplished before a product can be released to the market. Each of these line items needs to be captured in the backlog in order for the team to be aware of and plan for them. Examples of these are: having Governance messaging, such as Terms & Conditions within the platform being built; or having Risk & Compliance criteria that need to be followed.
The team needs to know the owner (executive or body) who can be contacted for each piece of work in order to get the correct wording, criteria around the placement, steps to be taken, etc. Anything added to the backlog is articulated by the owner, who can provide the reasoning behind why this is being added. These owners are also the ones to whom the work will be showcased. This helps in identifying demo attendees. If the team doesn’t know the owner, it can cause an unnecessary level of frustration and anger, because rework is often involved due to unclear requirements and the team “winging it”.
What information is needed to get the work done?
After having understood what is to be done and where we want to go, we now need to determine if we have all the necessary information to get started. Identifying what information is needed for each phase of the project early in the game preemptively removes blockers and quickens the pace at which the team is able to operate. Less time is wasted grappling to get access to items, and if there are missing items, owners can be identified ahead of time to procure these pieces. Pertinent information (such as access credentials for different repositories and tools, design documents, and schemas for implementation) should be shared once the associated Product Backlog Items are created. Making this information available can ease the stress and strain on your resources.
Do we have representation from everyone to be involved in the process?
When carrying out the work, all teams getting the product or service to customers need to be involved in conversations from the start. This is necessary irrespective of where in the process they fall. Representatives from Operations, Security, Legal, Marketing, etc., should be included from the inception and planning phase to account for all their requirements so that the team can have these items added to their backlog. This can ensure they are not forgotten and can be timelined appropriately. Having this level of inclusion from the start is also necessary to guarantee the proper considerations are being made, so that when it is that team’s time to do the work, the appropriate steps leading up to that point will have already been taken, thus resulting in the facilitation of a seamless and smooth process.
Which part of the system will generate the most revenue for the business?
Revenue can be generated on a platform in two ways:
- Directly by allowing customers to make purchases or payments (subscriptions, selling products in a marketplace, etc.).
- Indirectly by simply providing relief to customers through ease of use and firm security unlike other similar products on the market. Ensuring these can result in an increase in traffic and overall interaction with the service/platform which will inadvertently lead to an increased Net Promoter Score (NPS). A high NPS is useful for forecasting business growth and cash flow, as well as assessing overall customer satisfaction, and can lead to further buy-in from potential stakeholders.
Knowing what areas of the system fall within the above two categories will help the QA team focus more of its effort on ensuring these areas are top-notch quality. This will also help the Product Owner with their prioritization efforts to ensure there is a healthy mix of revenue-generating vs. feel-good features being released each Sprint.
These questions are hard-hitting ones that need to be asked on every project in order to guarantee alignment. Bear in mind that they are not the only questions we should be asking. However, they do provide a great starting point. As we listen to the answers being given, we can ultimately formulate additional questions to deepen and cement the understanding of everyone operating in the ecosystem. In future articles, I’ll be zoning in on and exploring which questions each role in the Agile ecosystem should ask to better improve their role.