Six Powerful Questions Every Agile Team Member Should Ask

1. 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.

2. 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.

3. 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”.

4. 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.

5. 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.

6. Which part of the system will generate the most revenue for the business?

Revenue can be generated on a platform in two ways:

1. Directly by allowing customers to make purchases or payments (subscriptions, selling products in a marketplace, etc.).
2. 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.