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.
More
Product strategy is the process of deeply understanding a market – customer needs/problems, existing competitors and likely new entrants, trends and the size of the opportunity.
From there, you can define your unique value proposition, set goals for your product, and create a product roadmap.
When you engage with CodeStringers your primary point of contact from day one will be a senior product executive with years of experience working on dozens of products who can guide you through the product strategy phase.
More
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.
More
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.
More
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.
More
Sounds easy, huh?
There are some pitfalls in story mapping thta are vital to consider.
- 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.
- 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.
More
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
Software Development Trends 2025: Expert Predictions and Insights
Software development is entering a pivotal phase of transformation, driven by groundbreaking innovations and evolving…
Top Three Predictions for the Future of DevOps
Imagine a future where DevOps is no longer confined to deploying code faster or automating…
Why Senior Leadership Involvement Makes All the Difference
In our previous two blog posts, we discussed how we engage with potential new clients…
How We Guarantee On Time Delivery
As a former software company founder I can tell you that a founder’s biggest fear…
How We Work With Prospective New Clients
Even though we’re an outsourcing company, we also get multiple solicitations a day from competitors…
Getting started with software development services is simple & painless.
Within a month, you can see your idea start to come to life.
