Our Process (Product Management & Custom Software Development)
As stated in our mission, the Product & Process Team is charged with handling and executing internal requests for custom software applications. We handle this through the following five (5) steps.
NOTE: the term, Program Increment (PI), appears several times below. A definition for Program Increment is: a discrete period of time during which a team delivers value in the form of working, tested software and systems.
- Intake: Begin by submitting a DoTS Intake form for a Custom Software Application. This is the formal initiation of the request by the business, and is meant to function as a single place to formally initiate a request. A PO from the Product & Process Team will be assigned to your request, and typically acknowledges and contacts the business about next steps within one week of submission.
- Discovery & Project Proposal: In this stage, the Product & Process Team will meet with the business to learn more about the nature of the request, the need(s) it fills, the value it adds, and the necessary features and functionality of the software. We will focus on creating agile, light-weight documentation that captures just enough detail to make a future determination of whether or not the project should move forward. Typically takes 2-3 weeks.
- Architecture Review: This is a technical conversation with only DoTS team members participating. The purpose of an Architecture Review is to discuss how a project would be executed if approved, define an architectural matrix for implementation, and ultimately determine whether a proposed software project is fit to advance in the next step of the project life cycle, Sizing and Estimation. The Architecture Review typically takes place 1-2 weeks after the Project Proposal has been finalized and approved by the business.
- Sizing & Estimation: Once the Architecture Review is complete, the Product & Process Team and other DoTS technical teams will use the list of features and functionality gathered from the proposal to estimate the relative size of the project or request. Relative size is not an estimate of time or resources, but rather an assigned value that is used to compare the “size” of projects relative to each other. A project’s relative size is expressed in story points (e.g. 27 story points, 53 story points, etc.). As projects are completed, the Product & Process team tracks the amount of time and resources needed in order to measure the team’s velocity, improve future sizing estimates, and deliver reliable projections for future requests. Sizing typically occurs 4-6 weeks after a request has been initiated.
- PI Planning & Collective Prioritization: The Product & Process Team implements an equitable, transparent, and sustainable process for determining which projects or requests are approved for implementation. It’s unrealistic to expect (and a poor use of resources to attempt) DoTS to deliver every request made by the business for software application development.
Therefore, the Product & Process Team leads a collective prioritization exercise, during which each project or request is considered relative to the district’s strategic roadmap, the value or expected return of each request, and DoTS’ capacity for the upcoming PI. These prioritization exercises are referred to as PI Planning. The objective of PI Planning is to collectively identify the most valuable or impactful requests, and collectively determine which requests move forward for execution in the upcoming PI. PI Planning occurs twice a year; typically 1 month prior to the start of each PI. See below in Cadence for Delivery for PI schedule.
Execution and Delivery: Once a project or request is approved for the upcoming PI, DoTS commits to delivering the request at some point during that PI. All projects or requests will be executed using DoTS’ standard Software Development Life Cycle (SDLC).
