The Scheduling Planning Routing Inter-satellite Network Tool, or SPRINT, is an opensource software tool that is currently under development at MIT's Space Telecommunications, Astronomy, and Radiation (STAR) Laboratory. It schedules, plans, and re-plans the activities of large Earth-observing satellite constellations under changing conditions. The SPRINT framework seeks to maximize observation data, minimize latency, and autonomously adapt to unexpected events. This is done by utilizing crosslink capabilities on the satellites, a master ground planner, and onboard local planners on each satellite. All planners run multi-integer linear problem (MILP) solvers. SPRINT is distinct from other satellite scheduling tools by utilizing self-replanners on the individual satellites: an unexpected addition to the plan, or an "injected observation," can be commanded by an operator. That satellite will then calculate a new plan for itself and the satellites around it, which will be propagated through the network.A tool such as SPRINT becomes increasingly important as constellation sizes increase and they become infeasible for operators to plan by hand. However, not every constellation architecture is well suited for observation and data management using crosslinks and replanning. For example, some have orbital configurations that make it difficult to support crosslinks for long enough to transfer a useful amount of data, and some constellation architectures have so many ground stations and overpasses that data downlink becomes trivial. These additional ground stations may become an unnecessary expense when SPRINT and crosslinks are added. We examine the benefits of using SPRINT on example state-of-the-art CubeSat and small satellite constellation missions, such as TROPICS, CYGNSS, and GeoOptics CICERO. We evaluate how modifications to these missions, such as changing the orbital spacing between satellites and the number of ground stations, can lead to benefits in data volume collected and downlinked, latency of data, and overall mission cost. One example finding is that is the addition of the SPRINT framework to the CYGNSS mission (with 8 small satellites) achieves similar data packet latency with one ground station as the base mission achieves with four.We additionally look at implementing SPRINT on affordable hardware to quantify its feasibility for low-cost small satellite constellations. To this end, we have developed a testbed for implementing the SPRINT platform on multiple Raspberry Pis to examine the speed of performance and processing. The testbed decouples the SPRINT framework to work on separate machines: the ground station network is modelled on a laptop computer, and each satellite is modeled by a Raspberry Pi. All communication between them is done with socket programming. We evaluate the testbed's performance for multiple constellation architectures and ground station network sizes using metrics such as run time and RAM usage and compare this performance to running the simulation on a single computer. We analyze ...