From Application Idea to Released Code

New features and functionality are constantly being added to our application and shipped to our clients on a regular basis. The ideas for those improvements come from a variety of sources but all follow the same path from planning to development to final release. But how exactly do we take an idea and turn it into something tangible that our clients will love? Grab a coffee, sit back, and let’s go through an overview of our process.

Keeping Track

Our current list of application ideas is quite large and growing. We regularly receive ideas from our clients, internal teams, and company partners. Some of those ideas are small in scale and can be finished by a single engineer in a few hours, while others will take our entire team of engineers months to complete. Keeping track of those ideas and the work they translate to, requires a robust project management and software development process. We follow Agile methodologies using the Scrum framework to work in short, iterative cycles so that we can continuously deliver incremental improvements to our application while at the same time collaborating with and receiving feedback from our clients. Shorter cycles also allow us to be flexible and to quickly respond to and embrace change.

Start with Documentation

All incoming application ideas are first documented. Most of those ideas will be documented in stories. A story is an agile concept that expresses ideas and their requirements from the perspective of an end user. They are non-technical and used to identify who will benefit from a proposed idea, what the benefit will be, and why the benefit is needed. Stories define the issues to solve but do not provide the solutions.

Prioritize the Important Stuff

All stories - along with tasks, issues, and bugs - are housed in a product backlog in our work tracking and project management system. A product backlog is a list of all items needed in our application that the Engineering and Product teams review and prioritize regularly. Top priority items are inspected for completeness in grooming meetings and assigned arbitrary units of measure called story points. Our team looks at the amount of work, complexity, degree of risk, and level of uncertainty when assigning story points to backlog items. We work hard to keep our estimates consistent with similarly performed past work.

Break Down the Work

The Engineering team works in short cycles called sprints. Sprints are used to break down larger items into smaller pieces that can be completed within a set period. We use our past sprints to help us predict how much work the team can complete in future sprints. This information allows us to get an accurate estimate of how long it will take for a specific project to be finished. We typically plan 3 to 4 sprints into the future but always allow for re-prioritization and changes.

Get the Engineers Coding

All our sprints start on Mondays and last for two weeks. Each sprint focuses on its own backlog of work which is pulled from the highest priority items in the product backlog. An engineer takes an item from the top of the sprint backlog and begins coding a solution. Once the coding is complete, it goes through several rounds of quality checks to ensure it is accurate, bug-free, and logically sound. Solutions passing the quality checks are moved to a testing environment for our Quality Assurance (QA) team to perform its own testing. Items passing QA review are marked as done and queued for eventual release.

Wrap Up the Sprint

All our sprints end on Fridays following two weeks of work. Items not completed in a sprint are pushed back onto the product backlog and may be picked up again in a future sprint. Successful sprints deliver all the work that the team committed to during the planning process. Our sprints end with a review followed by demonstrations of the newly completed work. The Engineering team also performs a retrospective to discuss what went well in the past sprint and what needs to be improved for future sprints.

Release the Code

The final step in our process is to get the new code out to our clients. We release new application changes to our production environment two weeks following the conclusion of a sprint. This cadence gives us enough time to perform additional regression testing, conduct internal training, and prepare customer communications on the newly completed features and improvements.

Utility Cloud customers benefit from the Agile process because it allows for constant innovation within our product and continual release of new functionality within our platform.  

Have an idea? Send it to us here!