The Opportunity Project for Cities sprint toolkit: A guide for community-driven innovation sprints in local governments
Lessons from Detroit, Long Beach, Macon-Bibb, and Miami-Dade
Read the TOPC companion report, which includes case studies, insights for local governments, and TOPC best practices.
About the sprint toolkit
This toolkit was compiled to support the Opportunity Project for Cities (TOPC) program, a 22-week innovation sprint through which local governments work with community and tech partners to develop open-source tools that leverage data to address pressing local challenges.
The Centre for Public Impact and the Beeck Center for Social Impact + Innovation at Georgetown University partnered to launch the TOPC program, and have developed this toolkit to document guidance based on pilot sprints conducted in San José, CA, and Saint Paul, MN, followed by a second sprint that included Macon County, GA, Miami Dade County, FL, Long Beach, CA and Detroit, MI. This toolkit is a living document that will capture best practices from the ongoing TOPC program. The TOPC program was developed with generous support and guidance from the Knight Foundation and Google.org. The TOPC program was based on The Opportunity Project (TOP), created by Census Open Innovation Labs in 2016. This toolkit was designed for local governments as a companion to the TOPx Toolkit for federal agencies. This toolkit was initially written by Katya Abazajian, Katie Stenclik, and Andrea Mirviss and the latest version includes contributions from Rebecca Ierardo, Harold Moore, and Brian Zuluaga. It was originally released on August 19, 2021, under a Creative Commons Attribution-ShareAlike license and should be cited as: “TOPC sprint toolkit: a guide for community-driven innovation sprints in cities” (2021). Washington, D.C.
Purpose and goals
This toolkit is a resource for people working in local governments to chart a path to transform public data into digital tools that address pressing local challenges while building participants’ skills for tech, design, and data use. TOPC brings together technologists, public servants, and community organizations to prototype solutions that use local data to meet real community needs. Read more about the latest iteration of TOPC in Macon County, GA, Miami Dade County, FL, Long Beach, CA and Detroit, MI in our 2022 sprint report, The Opportunity Project for Cities: Lessons from Detroit, Long Beach, Macon-Bibb, and Miami-Dade.
While CPI and the Beeck Center provided hands-on support to local governments to run complete TOPC sprints, this toolkit allows anyone to replicate the TOPC model on their own. By following the guidance in this toolkit, participants can:
Find meaningful applications for local data to tackle community needs;
Identify new models of collaboration with community partners and technologists through civic innovation; and
Learn ways to leverage human-centered design for public interest technology.
The sprint is designed to lead participants through an inclusive and collaborative process to design technology that centers residents’ needs and priorities. Cross-sector relationships can supercharge efforts to innovate when using public data and public interest technology and are most impactful when community members are active and engaged stakeholders in the work. Delivering equity through public systems requires incorporating the voices and needs of community members in civic innovation.
Even if you’re not able to replicate an entire TOPC sprint, you can adapt the milestones, tasks, and resources in this toolkit to design your own innovation sprint to co-create digital tools that serve your community. Anyone can use the lessons from this toolkit. Before you get started, we suggest reviewing the TOPx Toolkit Glossary to get familiar with key terms.
How to use the toolkit
Who can use this?
Public policymakers and decision-makers;
Tech-interested government staff;
IT, data, and innovation experts in government or working with governments;
Technologists working on public interest tech tools built from open government data; and
Community organizations partnering on government innovation projects.
A note on audience: The templates and guidance contained within this toolkit are designed predominantly for government practitioners, but we encourage community organizations and others who partner with government practitioners to leverage and adapt them to lead their own TOPC sprints.
Milestones to help you structure a TOPC sprint;
Step-by-step instructions for executing your sprint;
Tips and best practices; and
Resources from our TOPC curriculum.
What will you learn?
By the end of this sprint, you will have co-created a prototype of a tech tool that can grow into a robust and effective problem-solving resource for your city/county. This sprint is just the first step in a process to integrate your prototype into impactful innovation goals over time.
Along the way, you’ll develop skills in:
Human-centered design methods to incorporate community input and lived experience into tech and policy design;
Strategies to identify impactful ways to use local data;
Cross-sector collaboration with people from tech, government, and community spaces; and
Product development workflows that serve the public interest.
A core element of the TOPC model is investing in community relationships and leveraging data and technology for equitable outcomes. By running a TOPC sprint, you’ll develop stronger, more collaborative relationships with community leaders and residents. These relationships will help inform tools that are designed with the direct participation of the residents they serve and address real community needs.
Tips and tricks
To get your team started, consider these tips for overall sprint management. TOPC sprints can create fast-paced opportunities to build momentum around new ideas and applications of open data, but they can also be challenging for those who are new to civic innovation.
These tips can help you create a more seamless and engaging sprint for your participants. Read more about what makes a successful sprint in our 2022 sprint report, The Opportunity Project for Cities: Lessons from Detroit, Long Beach, Macon-Bibb, and Miami-Dade.
Be flexible about “data.” Local governments won’t always have the exact data that users ask for or need. Data can be any form of structured information, so think big about what constitutes data and how you can use the sprint process to improve the quality of data that’s going into digital tools.
Don’t let “perfect” be the enemy of “good.” The first solution is rarely the right one. This project is about building a prototype, and you’ll have limited time to complete it. The time pressure can help you get an initial product out, and by making iterative improvements to the product over time, you can pave the way for longer-term success.
Lose the jargon. Sprint teams should be made up of people from different sectors, but this means that jargon and other industry language may not be known to everyone. Ensure that your sprint team has ways to call out jargon and use more accessible language.
Recognize the importance of project management and facilitation. The sprint has many moving parts and diverse stakeholders from varying backgrounds that bring their own goals, personalities, and skills to the process. Leveraging these unique skills while also working towards a common vision for the sprint requires deft project management. Bring in expert project managers that can help form a cohesive team that empowers city/county, community, and tech partners to drive towards milestones in their area of expertise and meaningfully contribute to each sprint phase. Further, tap into expert facilitators for user research, research synthesis sessions, or other important sprint team workshops throughout the sprint. Project management and facilitation are not universal skills, and getting the work environment right is essential to ensuring that the sprint moves forward.
Prioritize community voices. Often, institutions and organizations can have strategies and plans that influence how and why public interest tech gets built. Pay attention to community members when they push back on the goals of institutions and organizations, seek to understand their interests, and try to adapt accordingly. Partnering with community organizations that are trusted by residents is one way to ensure the voices of those closest to the problem are prioritized. Providing funds or resources to support community partners’ involvement can ensure they have the capacity to fully engage with the sprint—and is just good practice.
Recognize funding needs and get buy-in from the start. Sustaining public interest in tech projects requires funding to continue improving, and support from leaders to iterate upon initial projects. Successful public interest tech requires collecting feedback and making systemic improvements over time, which requires funding.
Hold off on finalizing solutions, and don’t be afraid to shift course. Agile and iterative development means there will be changes throughout the project. Your sprint team shouldn’t know what solution they’re building until after community research is done. The best-case scenario is that your prototype does change significantly over the course of the sprint to adapt to new findings and deliver more meaningful outcomes that are aligned with community needs.
Products need owners. Product owners ensure products have what they need to grow and evolve over time. At a minimum, products will need edits, updates, and regular maintenance, while some products may require additional funding for software licenses or data storage. Without product owners, products end up with bugs or outdated information or simply do not meet community needs. A product owner doesn’t need to be the most tech savvy person; rather, they need to be someone committed to keeping your product up to date, available, and relevant to your community.
If people don’t hear about your tool, they can’t use it. You worked hard to develop your product - share that success with your community! Consider creative ways to introduce your community to your product. You might write a blog post, publish something in a local media outlet, or host a demo at a local event. Remember, this product is brand new to your audience - share how you worked with the community to understand their needs and develop and test your product. Consider also sharing ways you plan to continue to engage your community in the product’s future.
Planning a TOPC sprint
Use this outline to map out your TOPC sprint week by week. Feel free to stack some of the tasks to occur concurrently. At a minimum, the TOPC sprint should take 20 weeks, not including the pre-work conducted in Phase 0.
Phase zero: pre-launch
In this phase, which occurs in the months before the formal launch of the sprint, you’ll need to get your ducks in a row to run a successful sprint. This might mean having early strategic conversations with key stakeholders who can support your project and ensure it’s tied in with government and community policy goals. You’ll need to dedicate time and energy to building your sprint team. Collaborating across sectors means connecting with people who have different working norms and expectations. Use team-building exercises to ensure your sprint team is ready to go on day one.
Set up a cross-functional city/county team
Spread the word about the TOPC model and bring executive champions into the project. Share key resources like this toolkit, the report, and other resources about the TOPC model to ensure stakeholders understand the project and its goals.
Create touchpoints to engage key leadership and stakeholders. City/county leaders will be important advocates for improvements to your prototype later on, and building in regular opportunities to update them can ensure you’re not going it alone.
Use the roles and responsibilities resource to identify the appropriate participants to include in the team. As facilitators of the TOPC sprint, the city/county team needs to set internal roles before seeking out sprint participants, including additional city/county staff, community partners, and tech partners.
Use the RACI template to assign roles and responsibilities for all team members. Engaging the right people at the right times is essential to making inclusive decisions, gaining buy-in from key partners, and keeping the sprint progressing.
Define a problem area and project charter
Determine the problem area. Try to define a problem that is smaller than a general issue area (like “housing”) but larger than a specific challenge you already know about (like “difficulty accessing assistance”). A right-sized problem area leaves room for research to expose challenges but provides a clear direction for investigation.
Assess strategic plans of all major stakeholders. Look at the city/county and community partners’ strategic plans and identify salient issues with broad support and opportunities for tech improvement.
Complete the problem focus area template. Share them widely and ensure that anyone who might benefit from your work is aware of and supporting the project. This activity may also help to ensure resources, staff, and funding are contributing to sustaining and improving the product after the sprint.
Recruit and onboard community and tech partners
Make a list of potential community partners based on local organizations that directly serve residents, engage residents as members of their organization, or have working relationships with other community organizations. Find a community partner who has direct ties to community members, prioritizes equity, and is willing to provide substantive input on user research and product design.
Make a list of potential tech partners based on partners who will be able to lead development in the sprint, integrate community input into their work, and account for the longevity and sustainability of the product they build so that city/county and community teams can later support the products on their own. At a minimum, tech teams should be staffed with UX researchers, designers, program managers, engineers, and product managers.
Once your partners are onboarded, set up team norms, communications, and meeting structures. Share materials about the TOPC sprint, including this toolkit, the TOPC report, and other relevant websites or onboarding materials.
Building a team: characteristics, roles, and responsibilities
Sample informal agreement (community partner)
Sample informal agreement (tech partner)
Phase one: define and understand the problem
In this phase, you’ll conduct interviews and desk research to determine what your community needs from public data or technology. You will also identify what data this project needs and create a data inventory of the data you have available to use in your product. Leveraging human-centered design strategies, you’ll conduct interviews with people who have direct experience navigating the problem area you’ve selected and find opportunities for data to play a role in making their lives easier. It’s important to keep an open mind and remember that iterative learning is a core part of this process. Expect your ideas and understanding of the problem to change in new and exciting ways.
Launch user research
This section should be led by a research team that can focus and collaborate on completing user research.
A. Review research and understand the landscape
Review existing research or speak to key informants who can tell you how the problem area works, what major barriers exist, and how people generally navigate challenges. Have city/county and community teams present what they know to the sprint team so that tech teams and other stakeholders are up to speed with institutional knowledge. This may include presenting existing research on user journeys and known barriers.
Conduct a landscape scan of existing open-source solutions that address the problem area that your team is attempting to tackle. Speak to technologists who have attempted to solve this problem before.
B. Review research and understand the landscape
Set research questions that will expose new information about how data and technology play a role in the problem area in your user interviews. Ex. “Who’s working on this problem? What data do they need? Why do they need it? How do residents use data to address or navigate this problem?”
Conduct stakeholder mapping to identify which stakeholders are doing work related to your chosen problem area. Listing out these stakeholders or mapping them by influence and interest can help to identify who to interview for user research. Often, stakeholders can also connect you to other members of their trusted networks, like residents with lived experience.
Create a plan for building trust with potential interviewees, including by safeguarding their personal information. Separate interviewee names from interview insights and communicate to interviewees how their information will be protected.
Create an outreach list including potential end-users or people who have direct experience with your problem area. Begin conducting interviews to map the journey that residents take when dealing with your problem area. Pay particular attention to specific barriers and their location within the journey. Identify how data and information play a role in navigating that journey.
C. Document observations and insights
Conduct synthesis sessions to collate the user research and begin documenting observations from users about data-specific challenges and technical needs. Try connecting things people say in interviews to data sources that you have available.
Use whatever framework you like best (sticky notes, asynchronous brainstorming, interview tagging) to identify major themes from your workshops and isolate key insights. Highlight themes or insights that are associated with a high concentration of observations about data or information challenges; these might be particularly impactful to address with a technical solution.
Include a part of your synthesis workshop dedicated to exploring how people need solutions. What features matter to people dealing with this challenge?
D. Refine your understanding of the problem
Create a more detailed problem statement that is relevant to your problem area. A problem statement is a specific element of your chosen problem area that exposes the challenge that your future tool is going to try to solve. The problem statement should clearly identify who is affected by the challenge and why it matters to your community. You should also try to avoid including an answer to the problem within your problem statement.
Conduct a data inventory and assess quality
This section should be led by a data team that can focus on compiling relevant data, assessing its quality, and preparing it for use.
Create a list of data systems with information relevant to the selected problem area. Liaise with owners of those data systems, including looking across departments and jurisdictions to build new relationships with data owners. The list of data systems does not need to be complete in order to be helpful!
Create a list of datasets, or a data inventory, that includes which system data is contained in and other relevant metadata. Share the data inventory with sprint teams and begin ensuring that data in the inventory is accessible and usable. Consider that the data that you list here should connect to your problem understanding research and be used to determine which solution you ultimately pursue in the next phase connects to the data that you list here.
Review your data inventory and identify data that maps to the problem statement. Any data that was highlighted by user interviews can be considered high-value data.
Improve data that is not high-quality by working with data owners to process and analyze raw datasets, with a focus on improving high-value data. This often takes time, resources, and data processing expertise.
Investigate any needs to protect sensitive data. Make plans to protect personally identifiable information if any exists, and work directly with project leaders, including the product owner if one exists, and data owners to ensure that data protections are written into data and product governance.
Brainstorm and prioritize solutions
Work with sprint participants to think creatively about how you might address the problem statement identified in the synthesis stage. Don’t be afraid to take a few turns at brainstorming solutions and vetting them with city/county or community leaders to assess viability.
Connect available data to proposed solutions by noting where research participants noted a need for improved access to information or increased government transparency. Give additional weight to solutions that make use of high-quality, available, high-value data that is requested by residents.
Prioritize solutions by feasibility and potential impact. Think about feasibility as the likelihood of your sprint team being able to execute this solution in your allotted time. Ask yourself questions like: Does this tool require data, resources or buy-in from people not currently involved in this sprint? Does this solution require us to work at maximum capacity for an extended period of time? See attached resources for examples. Consider which community partners might support the tool, and count this under feasibility. Spending more time in this phase ensures a more impactful product later on.
Decide as a team which solutions are most feasible and impactful. Actively seek input from community partners and their constituents to decide whether solutions are a right fit for the sprint process. Be sure to socialize final ideas with senior leadership and sponsors early on.
Take a beat to sit down with your team and think about where you’ve been and where you’re headed. Thinking about impact and sustainability is often left to the end of projects. Plan ahead by conducting midpoint workshops with your team to understand what you’ve achieved so far, what you hope to achieve, and how you might ensure that this project lasts into the future. Important questions to answer might be:
Who owns improvements to the prototype after the sprint?
How do these improvements get funded?
What might be the deeper, broader impact of the tool?
What do we need to set in motion now to have that impact?
Conduct an impact evaluation workshop
Ask your team to articulate exactly what is the expected impact of this work. Then go through the impact evaluation template and think through how your expectations match with reality. Evaluate the inputs, activities, outputs, outcomes, and impacts associated with your project.
Engage stakeholders to review your impact evaluation plan. Sharing an impact evaluation plan is a helpful way to let key stakeholders know what to expect and build buy-in for the future. Possible stakeholders could include executive champions who are not directly involved in your sprint or community leaders who are affiliated with your community partner organization.
Plan for impact evaluation in the future. Identify outcome and impact metrics that measure the equitability of your tool and the effects it has on users’ experiences.
Confirm product owner(s) and identify funding
Identify a product owner who can liaise with tech experts, delegate improvement tasks, report up to leaders, and define the strategic direction of the work. This doesn’t have to be a technologist, but they should be well-versed in communicating with tech workers.
Prototypes need investment to survive. Plan ahead to identify funding streams associated with existing initiatives, upcoming grant opportunities, or even revenue streams that might sustain the tool’s use.
Start sustainability planning
Work with the product owner to complete the product sustainability checklist to ensure they have the tech capacity, funding sources, and data linkages they need to keep the product running.
Hiring staff to support improvements to the prototype is the best way to ensure that prototypes are improved and integrated with broader strategic goals into the future.
Phase two: design and prototype
In this phase, you’ll start building your prototype! You might prioritize spending time agreeing on features and elements of a successful tool with your sprint participants, or you could choose to begin by designing with target users and identifying additional features along the way. Regardless, you’ll need to adapt your product to users’ needs throughout this phase. Working in the open and building structured opportunities for community and stakeholder feedback into your process can improve the quality of your finished product.
Build wireframes or initial prototypes
Using everything you learned in the problem understanding phase, work with the tech team to build out wireframes that prioritize users’ preferred ways to access information or data. Be sure to consider the accessibility needs of the population.
Begin noting where data linkages will be needed to ensure that data flowing through the prototype is updated automatically and with any necessary quality checks. Pull data owners into conversations as needed to validate expectations about data linkages.
Conduct user tests
Work with your community partner to organize user tests made up of target users for the product. Note: beneficiaries of the product and target users might be different groups! Think about who will actually be using the product and speak directly to them.
Use best practices from Civic User Testing (CUT) group models to ensure that sessions are designed to be inclusive and engaging to participating community members.
Consider varying formats for how and when you test. Handouts might be great for one audience, whereas a very stripped-down demo that people can click around might be good for others.
Compensating users participating in tests for their time based on the recommendations of local community organizations and service providers is a best practice that shows appreciation for the time and contributions of your testers and encourages participation.
Build the final Minimum Viable Product (MVP)
Work closely with community partners and target users to integrate user feedback into the final MVP and set up data linkages that will make the prototype work.
Liaise with data owners who are contributing data to the product to ensure that data will be stored appropriately in city/county or community partner data systems, and revisit data protection needs identified in Phase 1. Ensure that workflows exist to update the data regularly and that relevant data owners are read-in to their responsibilities with regard to the product’s maintenance to keep it up-to-date and accurate.
Conduct any final feedback sessions to ensure that final designs are aligned with the expectations of all stakeholders and team members. Prioritize feedback from community partners and adjust course depending on their expressed needs.
Phase three: product launch
Time to launch your product! Let the world see what you’ve created. Remember that this is just the first step toward longer-term solutions that can make a difference in your community. Use this prototype as a foot in the door to building bigger and better things.
Demonstrate the MVP
Communicate the definition of an MVP to any key stakeholders and sprint participants to ensure that your collaborators understand the role of an MVP. Ensure that they understand the benefits and shortcomings of the tool and how it might improve over time, with the right support from stakeholders.
Share your product with anyone who has helped you along the way! Use this as an opportunity to open up a dialogue with community members and share how and why you built this prototype. Consider hosting a “Demo Day”, an event where you publicly launch and showcase your product to your community.
Launch and collect feedback
Create permanent channels for users to submit feedback about the tool. This might be adding a comment form, providing contact information for the product owner, creating usability guides for open-source documentation, and more.
Continue incorporating feedback into the design of the tool and hand off recommendations to the product owner.
Plan for long-term sustainability and iteration
Work across city/county and community teams to chart a path toward sustainability of the product, including by identifying funding streams and decision-making about the tool’s future.
Identify which tech team participants will be available to support with tech transitions. Ensure you have a plan for hosting the tool and sharing access to adapt source code.
Develop a sustainability memo that highlights key takeaways, including ownership, funding streams, community partners/programs, and high-level strategic goals. Share this memo with your partners and key stakeholders!
Now that you’ve launched the first prototype of your product, you can start working with your team to make sure the product can continue to grow and change over time. In this phase, you may need to work with a wider range of stakeholders to ensure your product has a long-term home and consistent resourcing.
Explore ways to support product ownership
If your sprint team’s product owner is still getting the hang of product ownership or if you need more time to build a consistent product development pipeline, take time after your sprint to work through what capacity you need to support your prototype from a product management perspective moving forward.
Make plans to hire people with product management or development skills once you’ve completed the sprint so that you’re able to bridge any skills gaps required post-sprint.
Explore the possibility of hiring contractors to continue iterating and improving on the prototype you’ve built, but make sure they are working with the intention of building on your community research and keeping community members involved in product improvements over time.
Review procurement needs
Once you assess your product and product owners' needs, you may need to procure additional staff or resources. Begin involving procurement professionals in your conversations about planning for the future development of your prototype.
Explore funding opportunities that might help you prepare to procure software or talent to help keep your tool alive, and start planning for the future by connecting funds to potential future iterations of your tool. Do some research on parallel costs for similar work with governments in other places and explore whether there are contractors your city/county already works with or could work with in the future that are appropriate for your budget.
Identify marketing needs
While a well-designed product can attract users organically, you’ll likely need to invest in communicating your work and launching your product with prospective users. Work with marketing and communications professionals to give your product a public boost and acquire a base of users who can benefit from your tool.
Begin by making a marketing plan in the weeks or months after your sprint, and include opportunities for community members to inform improvements to future iterations of the product by working to create opportunities for public feedback after launch.
The comprehensive TOPC sprint checklist
Need to fast-track your way through a TOPC sprint? Use the resources below to hit major milestones while prioritizing important elements of the sprint, like community participation in co-designing your prototype. These resources are designed for government practitioners, but community partners can adapt and use them as well.
Review the TOPC toolkit and learn the sprint curriculum
Start building a core team using our roles and responsibilities worksheet
Select a community partner using these selection criteria
Select a tech partner based on their agreement to the sprint prototype criteria
(If needed) Sign partnership agreements with your community and tech partners
Select a problem focus area for your sprint by completing this template
Complete this RACI matrix with your team to stay organized across stakeholders
Data team: Begin the data inventory template and complete the data inventory
Research team: Begin the user research plan template and complete user research
Synthesize data and research with our synthesis, ideation, and prioritization facilitation guide for virtual or in-person cross-functional teams
(If needed) Update your problem statement based on synthesis results
Choose a prototype based on best alignment with data, feasibility, and impact for residents most affected by the problem
Describe your selected prototype and have your tech partners begin development
Practice filling out an impact evaluation template and create an impact evaluation plan
Assign a product owner who can manage the product after the sprint has concluded
Product owner: Begin completing the sustainability checklist
(If needed) Revisit your RACI matrix to include development roles and responsibilities
Test your prototype by following our user testing guide. Manage the user testing process with a template sign-up sheet and tracker
Prepare to demo the first version of your prototype with our Demo Day prep package
Finalize and launch your MVP with resident feedback
Huddle with your team to plan for product management, marketing, and procurement moving forward after the sprint! Plan changes with ongoing resident feedback in mind.
At the Centre for Public Impact, we believe in the potential of government to bring about better outcomes for people. Yet, we have found that the systems, structures, and processes of government today are often not set up to respond to the complex challenges we face as a society. That’s why we have an emerging vision to reimagine government so that it works for everyone.
A global not-for-profit organization founded by the Boston Consulting Group, we act as a learning partner for governments, public servants, and the diverse network of changemakers who are leading the charge to reimagine government. We work with them to hold space to collectively make sense of the complex challenges we face and drive meaningful change through learning and experimentation.
The Beeck Center for Social Impact + Innovation at Georgetown University reimagines systems for public impact using design, data, and technology. Beeck Center projects test new ways for public and private institutions to leverage data and analytics, digital technologies, and service design to help more people.
The Knight Foundation strives to foster informed and engaged communities, which they believe are essential for a healthy democracy. The Knight Foundation invests in journalism, the arts, and in the success of cities where brothers John S. and James L. Knight once published newspapers.
Google.org brings the best of Google to help solve some of humanity’s biggest challenges — combining funding, innovation, and technical expertise to support underserved communities and provide opportunity for everyone.
Lessons from Detroit, Long Beach, Macon-Bibb, and Miami-Dade
Read the TOPC companion report, which includes case studies, insights for local governments, and TOPC best practices.