Let's Talk Software

Even if you're not looking for custom software development, we're happy to chat about agile processes, tech stacks, architecture, or help with your ideas. Enter your contact information below and a member of our team will contact you.

    Clients who trust us to deliver on their custom software needs.
    Tonal Logo
    Aquabyte Logo
    More Cashback Rewards Logo
    MasterControl Logo
    Little Passports Logo
    Mido Lotto Logo
    Software Development Capabilities

    Manage Risk and Improve Predictability with Agile Release Planning.

    Things rarely go according to plan. However, Agile Release Planning assures that you stay on track as your original plan evolves.

    Our Agile Release Planning Services.

    When you engage with CodeStringers, your primary point of contact – your engagement manager – is a senior product executive with years of experience working on dozens of software products in multiple industries.

    Unlike large consulting firms that would assign junior people and charge a fortune, CodeStringers will guide you through agile software release planning expertly, efficiently, and at no cost.

    Yes, you read that correctly.

    For qualified potential clients, we provide this “discovery” service at no cost. Why?

    It’s unrealistic to expect a potential client to hire us if you don’t yet have a plan including duration and budget. So we help you create that agile release plan on our dime. It’s a great way to ensue the relationship is a “fit” and for you to see how we operate as an organization and your custom software development partner.

    Product Strategy

    The first step in building any software product is to identify a “cohort” of people or organizations with a common need or problem that you believe you can uniquely address. How do you take that idea and begin shaping a plan?

    User Persona Definition

    Every software product is intended to address the needs of one or more “cohort” of users – people with similar needs. A user persona is a fictional character defined to represent a cohort.


    The user persona helps the entire development team understand who their customer is – the common attributes, behaviors and needs.

    Defining personas requires research, which can be done through surveys, interviews, observations or analysis of existing customer data.

    CodeStringers’ product teams will guide you through this research, help you analyze the results, and define detailed personas including demographic and psychographic informmation, goals and motivations, pain points and use caes that your software product may address.

    User Interface Wireframing

    As the saying goes, a picture tells a thousand words. Wireframes are the pictures of your product.


    Wireframes are visualizations of stories, but rather than viewing each story in isolation, wireframes show you how multiple stories – features and functions – work in concert to support a user’s journey.

    Wireframes will illustrate the layout of the product including navigation, and content areas. They will show the information hierarchy of the product. And for complex features, they’ll start to illustrate the experience. Wireframes are a communication tool. They help CodeStringers show a potential client what their product might look like and they help the development team envision what they read in the story map.

    Journey Mapping

    A user journey map is a means of visualizing the flow a user takes to achieve a goal using a software product. A software product may have anywhere from a few to dozens of journeys. Journeys are invaluable in helping the development team envision how software may solve problems for users.


    Journeys illustrate a user persona interacting with the software as a timeline; as touch points between the user and the software; and as actions of the user and his/her thoughts/feelings.

    User journeys are a critical step in defining functional software requirements because ech interaction between user and software represents a feature or function.

    CodeStringers product team can efficiently but thoroughly guide you through journey mapping for your product.

    Story Mapping

    Story mapping is the process of translating user journeys into unique features and functions – user stories – and organizing them into groups of related functionality – epics – and into version releases.


    Sounds easy, huh?

    There are some pitfalls in story mapping thta are vital to consider.

    1. Breaking down large stories into small chunks. For example, you might have a story to illustrate data in a data table. But you should break that down so that every filter, search, sorting, pagination and other functionality become individual stories. Failure to do this will most definitieely result in under-estimation by the team, which translates to a missed release date and/or budget overruns.
    2. What is and is not needed in each release? How do you prioritize? There are dozens of prioritization methods and none fit every product. or organization. Moreover, there’s as much art as science to prioritization. That doesn’t mean the approach is “trust your gut”, but there. isa health balance of quantitive and qualitative inputs when prioritizing.


    Despite the dictionary definition of the word, an “estimate” usually becomes a commitment. Some believe that accurate estimates are a myth. Although they are never perfect, experience improves them. Most software firms might estimate a couple of releases a year. CodeStringers estimates dozens.


    The more atomic each story is in a story map, the more accurate estimates are. It’s simply faster and more precise to estimate small tasks versus large ones.

    Additionally, by building dozens of products each year, CodeStringers sees commonality across thos products, which allows us to apply real-world experience – the actual effort it took to build a feature when we’re estimating a similar one.

    CodeStringers estimates every release twice: one in time (hours) and the other in story points. Once we’ve executed a few sprints and establish the team’s velocity, we can then divide the remaining product (release) backlog by the velocity. We then compare that to the original time estimate. We not only know if we’re ahead of or behind schedule, but we also learn to imrove our time estimates going forward.

    Key agile release planning information.

    Below is a taste of CodeStringers’ expertise in agile release planning and development. For more on the types of agile methodology, check out our blog post.

    What’s a User Story?

    A user story is the definition of a software feature to be built. User stories have a specific format that includes four fields (three illustrated in the picture above):

    • Who is the user persona for the feature?
    • What does that user persona want the software to do?
    • What goal does the user persona have that the feature will achieve?
    • The “Definition of Done” in the form of listed acceptance criteria.

    The term “user persona” simply means a description of the prototypical user of the feature. Software products may have a single or multiple user personas.

    The format of the story is:
    • As a <user persona>…
    • I want to <what the user persona wants the software to do>…
    • So that <the objedctive the user persona wants to achieve>.

    Acceptance criteria are typicallly use cases. One use case is the “happy path”… what happens if the feature works as expected. The others are “negative use cases”… what happens when the software doesn’t do what the user wants.  For example, take a “login” feature:

    • The happy path is that the user inputs a username/email address and a passsword and gains access to gated functionality.
    • Negative use cases are what happens when the username/email is bad; the password is bad; both are bad… in the case of a mobile app, what happens when there’s no connectivity.
    Well written user stories meet six criteria articulated as the acronym “INVEST”:
    • INDEPENDENT: Each story must not have functionality that overlaps others. Login is independent of password reset, for example.
    • NEGOTIABLE: Perhaps the most forced word in this acronym, “negotiable” simply means that the team can understand the story and acceptance criteria.
    • VALUABLE: Each story creates value for the customer.
    • ESTIMATABLE: The team can size the effort to deliver the story.
    • SMALL: Stories are small enough to be completed in one sprint… perhaps even smaller. Some organizations dictate that stories must take less than a few days. Stories that are too large are often too complex and need to be “broken down”. 
    • TESTIBLE: The acceptance criteria for the story can easily be translated into test cases, eaching having an expected result. When tested, if the expected result does not occur, a defect exists. The story is not “done” until all defects are cleared.

    Estimating User Stories

    Estimation of user stories is done by assigning a numeric value to each story called “story points”. Story points are an abstract concept but an important one in terms of the psychology of a development team.

    Prior to Agile / Scrum, development team members were all asked to provide estimates in time for everything they did. This was often referred to as “man-hours”. The problem is that each feature built could involve multiple team members, each one having to provide an estimate. Consider building a web application. You have a UX/I designer, a frontend web developer, a backend API/service developer, a database architect, a manual quality assurance tester, and a test automation engineer. Each one must complete work for a given feature to meet the acceptance criteria.

    How much time would it take to get estimates from each team member so that you know the total effort? How do you know if those estimates are accurate? What culture does it create when team members give estimates that are wrong (low) and are later criticized for the inaccuracy?

    Enter the Story Point

    Story points are a numeric value that the team collectively assigns to each story in the backlog and does so using “relative” estimation. Rather than each individual answering the question, “how many hours will this take?”, the team together is asked, “what stories that we built historically is this larger than and which ones is it smaller than?’

    Most development organizations use Fibonnacci numbers as their story point values: 1, 2, 3, 5, 8, 13, 21, 34…

    So, how does it work?

    The team looks at a given story and realizes it is larger in effort than one story built recently and smaller than another. The first of those took 13 points. The latter took 5 points. So, the estiamte for this story is 8 points. And move onto the next story.

    Why is this method valuable?

    #1 – Speed

    Ask people for time estimates and they’ll spend time trying to make sure they’re not low in their estimate.

    #2 – Less Sandbagging

    Ask people for time estimates and they’ll likely estimate high on purpose because it’s better to “under-promise and over-deliver”. Problem is that this may get to the point that estimates are so high they are of no value. Worse, once people are told that an estimate is accepted, they may find ways to actually use all of the time they’ve been given to deliver (i.e. they don’t work hard).

    #3 – Culture

    Asking individuals for estimates creates a individualism culture, which is the fastest path to a low productivity product organization possible. As the saying goes, “There is no ‘I’ in TEAM.” When you ask teams to estimate together, no one person feels politically exposed. If the team is wrong, we learn from it. In the case where a person is wrong, blame is assigned.

    Velocity Explained

    The term “velocity” refers to a unit of measurement in Scrum that illustrates the average number of story points completed in sprints. It is hugely important for a few reasons:

    #1 – Planning Future Sprints

    It’s important to plan sprints such that the volume of points planned is slightly higher than velocity. Why? Because you always want your team to have goals that push them to increase velocity but not so much greater than velocity that the team feels defeated.

    #2 – Release Estimation

    Scrum as a methodology does not discuss release planning, but the reality is that few if any product versions only require one sprint to complete. Releases typically include multiple sprints.

    Businesses need predictability. How do you plan sales and marketing activities if you have no idea when a product version will be released? How do you forecast revenue and profitability? You don’t.

    As such, velocity allows teams to estimate product version release dates early in the release development. Here’s how it works.

    The team completes a few sprints to establish a velocity of 50 points (per one-week sprint). The team then estimates everything remaining in the product backlog (for that product version) to sum to 2,000 story points. Divide the sum of the backlog estimates by the velocity: 2,000 / 50 = 40 sprints/weeks.

    Now decisions can be made. If the organization needs the release in 30 weeks, it may be possible to add resources to increase velocity. Moreover, the organization can now track progress sprint-by-sprint to ensure that the team continues to track to the release date and adjust as needed. No suprises at the end. of a cycle.

    Related Posts

    Getting started with software development services is simple & painless.

    Within a month, you can see your idea start to come to life.

    Get started utilizing our software development services
    STEP 1


    We complete a series of discovery workshop sessions that take anywhere from a one day to a couple of weeks depending upon the complexity of your idea. The workshops help our team understand your vision and gather sufficient information to create an agile software release plan.

    STEP 2

    Release Planning

    Our team creates an agile software release plan including customer/user personas and needs, feature requirements, user interface wireframes, technical architecture and tech stack, and estimates of effort duration and budget. In order to tailer our software development services to your needs, this plan is an essential step. This typically takes one to two weeks to complete.

    STEP 3

    Engagement Model & Team Structure

    Within days, we agree upon the best customer engagement model for your needs, the skillsets needed, and the structure of the team.

    STEP 4

    Build Software & Track Results

    We initiate agile / scrum development utilizing CodeStringers’ expertise and experience with the methodology. We conduct routine status reviews and demos, give your team direct access to a test environment for your software, and provide progress reports on features completed, QA testing results, and a burn down against the original release plan. If our estimates were low, we know early on. CodeStringers adds resources to hit the deadline at no cost to you.

    Scroll to Top