PLAY Introduction

Specifications are the ‘how’ we will do it of a requirement. This bridges the business requirements to the solution. Often specifications are technical in nature, but don’t have to be, as any requirement can be decomposed into great specifications. The ‘spec’ is a plan or strategy for how to build a solution for the requirement.


2-10 depending on the size of the team. If it becomes larger than 10 people consider breaking out into smaller groups.


30-60 Minutes. No one wants to be in a meeting longer than needed. Try to keep it short and sweet.


Practitioner to Master. It may take some practice to run this play.




Prior to this play you will need to have a clear requirements defined. Run the Defining Requirements play first if you haven’t already. Requirements should be prioritized and rank ordered so that you can focus on the top items. Run the Prioritizing Work play to determine what are the highest priority requirements to work on.


The right people are key to the success of this play. Review the invite list to ensure that all the various experts are in the room.


Virtually or in-person it is critical that everyone has face-time with each other. So make sure that if attending virtually that everyone can connect in video chat. You will also need to share ideas, so a whiteboard is important and a space that fosters creativity and innovation. 



All of our plays are five steps or less! However, you may need to run multiple plays to get the most out of this one. Don’t worry – you can do it! Learn the play, rehearse it regularly, apply it in the field and debrief on the outcomes. If it worked well, use it again; if it didn’t, find out why. Are there new factors in the system you need to consider, or do you just need to keep practicing? If you need help or have questions on this play, contact us!



Who are the players?

Every winning team knows which players to have on the field and what talent you need on the ready. To successfully deploy this play you will need the following roster:

Meeting Facilitator: Likely this is you! But you don’t have to do it alone, ask a friend (think of it like a football team that has a coach for different parts of the team). Skills needed:

  • Keep the team focused on the goal!
  • Foster a positive and creative space for all.
  • Organized and prepared to run play.

Subject Matter Experts (SMEs): A SME (pronounced S-Mee) is critical for this play. They will help drive the team to a shared understanding of what is needed to win. Skills needed:

  • Specific domain knowledge, narrow and deep rather than broad and shallow.
  • Communication and team collaboration. They must be able to share with others the knowledge they have on a particular subject. 

Solution Architect: This person is in charge of leading the practice of designing, describing, and managing the solution engineering in relation to specific business problems. Skills needed:

  • Finding the best tech solution among all possible to solve the existing business problems.
  • Describing the structure, characteristics, behavior, and other aspects of software to project stakeholders.
  • Defining features, phases, and solution requirements.
  • Providing specifications according to which the solution is defined, managed, and delivered.
Get the field ready!

Schedule the meeting in advance. Don’t wait until the last minute to schedule the meeting. You want people to be excited about it but not so last minute that they have no time to prepare.

Include an agenda. Set expectations – this will help keep your meeting on track. Include schedule and any prep work needed. Also let them know if it is okay to invite others or not. Remember that if you have to many people in the meeting, it will be difficult to facilitate brainstorming sessions without breaking out into smaller groups.

Prep the room. Arrive early and get ready. If it is in a physical room, get whiteboards ready, enough chairs for everyone, water and snacks are always a hit! If virtually, a central location for notes, brainstorms and follow-up items. Test connectivity in the meeting room and make sure there is enough seats for all participants.




It is critical that everyone has a shared understanding of the problem (requirement). Often the group wants to jump to solutions, but a review of the problem will save so much time down the road – it’s worth the time to do this now.

  • Review highest prioritized requirement with team. Focus on a single requirement. 
  • Ask the team if there are questions on this requirement. Is the problem statement: 
    • I” ndependent (of all others)
    • N” egotiable (not a specific contract for features)
    • V” aluable (or vertical)
    • E” stimable (to a good approximation)
    • S” mall (so as to fit within an iteration)
    • T” estable (in principle, even if there isn’t a test for it yet)
  • Update requirement to be INVESTable and confirm team has a shared understanding
  • Review next highest prioritized requirement and repeat above process. STOP when requirements that will be worked on in next iteration have been reviewed. Do not try to review all requirements in project. This is a waste of effort unless under a contract or project is purely a waterfall approach.

After a shared understanding is confirmed for each requirement, it is now time to dig into what is the plan on how to solve it. For complex requirements, this may need to be done after the team has had an opportunity to brainstorm offline. For simpler requirements this can be done in the same meeting.

  • The Solution Architect should lead the discussion on potential solutions to solve for the requirement. The solution should be a strategy or plan. Shift the team thinking to, “In order to meet this requirement, we should consider this approach __________ (specification).
  • Pitch solution strategy to team for requirement. This should be no longer than 5 minutes to explain. If it takes longer than 5 minutes to describe, this likely means the requirement is to large and should be split into multiple requirements and go back to Shared Understanding activity.
  • Present any alternative solutions and discuss pro/cons of strategies.
  • Pitch next solution for next highest prioritized requirement and repeat above process.

The objective is to have a team agreement on the solution strategy for the highest prioritized requirements. Some organizations may formalize this process and have a sign-off for each requirement and specification. Others may be a more informal review and thumbs-up approval.

  • Document the solution strategy within the requirement as a specification. This must be easily accessible by the resource who will build the solution and the team for acceptance later on.
  • Review documented specification with team.
  • Gain acceptance and approval on specification by any key stakeholders.


Want to learn more about INVEST and software development? Start here with this definition from Agile Alliance.



Time to run the Team Huddle play. Ask the team the following questions and then take a vote. Keep follow-up questions to a minimum and capture any issues raised as an offline follow-up (and be sure to follow-up).

Understand the play?

The play was understood and I asked any questions in time!

I’m not sure I understand and I have some questions …

I did not understand the play or my part in it.


Did you get in the game?

Yes, I made my moves and was in the right place at the right time!

I’m not sure I understand what I was supposed to do …

I kept the bench warm and watched from the sidelines.


Ready for what’s next?

Yes, I know the game plan and ready to win!

I’m not sure what’s next or if I am involved …

No clue what’s next and would rather sit it out.




Phew! The hard part is done! You might be tempted to go further and discuss the next set of requirements – but don’t boil the ocean in one go! Instead congratulate the team on a very successful and productive meeting!


If needed, schedule another meeting. For large projects you may need to repeat this meeting several times to identify specifications for the next prioritized requirements. Don’t worry, once the team gets the hang of it, the next meeting(s) will go much faster and smoother.  

Publish specifications for each requirement in a central repository that the team has access to immediately. Even better if it is someplace that the team can add comments or collaborate on. Keep the creative chat going!




You did it! Now just a few follow-up items:

  • Reflect on the play. Ask yourself how it went? What could have gone better, what could have gone worse? In sports this is watching the game again to see any plays that could have been better. Update your playbook. Build feedback loops that help you see what’s working; what’s not; and how to continue to develop the playbook by learning, adapting and iterating constantly as situations change and new challenges arise.
  • Contribute to the community of Playbook.Ninja. Sign-up for an account and receive updates on when new plays are added and help others by commenting on the plays with what worked or your experience.

Thank you for being a Playbook.Ninja


Share with:

How useful was this Play?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this Play.

We are sorry that this Play was not useful for you!

Let us improve this Play!

Tell us how we can improve this Play?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>