Abstract: Counterterrorism or Counterintelligence? Evidence or Cyber? Intelligence or Criminal? How do you prioritize mission critical system needs when national security is on the line?
Like any good piece of software, the product and process by which it is created should be informed by the user base itself. Let’s consider a few unique attributes of Sentinel – the Case Management enterprise software used by approximately 30,000 FBI employees and contractors every day. First, users must use it. Unlike the Facebooks, Instagrams, and Spotifys of the commercial industry, like many government products Sentinel is a required tool in the day-to-day life of these hardworking folks. They cannot merely ‘delete their account’ or choose a more desirable alternative. So, that means we don’t care if they like it, right? Wrong, usability and system acceptance are essential to enterprise buy-in and efficient operations.
Second, the FBI’s unique and varied user community poses additional challenges. Users across all levels and operational Divisions of the organization are matrixed by role; including Special Agents, Intelligence Analysts, Management, and Administrative Support Staff. Each of these roles has different (and at times, conflicting) priorities and expectations from the application. Whereas Intelligence Analysts and Support Staff are a demographic whose work is primarily conducted on a computer, Special Agents require minimized time in the office and maximized time out in the field conducting their investigations.
Each FBI Division has a unique mission critical focus and specific operational needs. So how do you prioritize the needs of each overarching division, while still ensuring each individual’s usability needs are considered? Is it possible for a single Product Owner to manage and negotiate such conflicting priorities? Not without a process and structure for evaluating and maturing the various requests.
The scaled solution we’ve adopted is a two-tiered backlog. The initial candidate backlog contains high-level concepts and requests sponsored by a specific division or individual users. Each quarter, using enterprise representation and a roadmap structure, a number of priority items are agreed to and then assigned to various scrum teams to evaluate and decompose. Ultimately each of these high-level backlog items turn into the epics and user stories we all are familiar with as agile software professionals, thus becoming the working backlog.
Let’s be honest – no one wants to frustrate a federal law enforcement officer. Everyone’s had experience with “tough customers,” but we’ve learned some important lessons about requirements gathering and software delivery through our time with the FBI that likely can translate to both government and commercial teams alike.
Learning Outcomes: - - Understand how to engage management in high-level decision making, while retaining agile flexibility with the Product Owner at the story development and implementation level
- - Understand how requests from a broad range of users can be filtered and focused into a workable backlog
- - Understand how to strike a balance between operational and usability needs
