Author: cprime-admin

The sprint is a container for Scrum events. It contains all the work a Scrum team will do to create an increment (which is formed when it meets the quality measures required for the product as defined by the team’s definition of done). The sprint is the heartbeat of Scrum. 

In her blog, 5 Powerful Things About the Sprint, Stephanie Ockerman covers how the sprint provides:

• Focus (where ideas are turned into value)
• Predictability (deliver a ‘done’ increment of work)
• Control (to inspect an increment and adapt)
• Freedom (for Scrum team to self-manage, collaborate, and experiment)

The first event of a sprint is sprint planning, which lays out the work to be performed for the sprint. The output of sprint planning is the sprint goal—a concise statement of what the team intends to accomplish during the sprint—and the product backlog items selected for the sprint, also known as the sprint backlog.

Why create a sprint backlog?

The Scrum Guide describes the sprint backlog as a plan by and for the developers. It is a highly visible, real-time picture of the work that the developers plan to accomplish during the sprint in order to achieve the sprint goal. 

The sprint backlog is solely owned by the developers, but the Scrum team collaborates over the work on it. For example, if the developers believe the work in the sprint backlog needs to change to better meet the sprint goal, developers would collaborate with the product Owner when making that decision. The sprint backlog is still owned by the developers.

The sprint backlog contains a commitment—the sprint goal—which provides the ‘why’ for the developers. It enhances transparency and focus against which the team can measure progress.  The sprint goal helps to answer questions like:

• Why is it worthwhile to run this sprint? 
• What assumptions/hypotheses do we want to test?
• What is it we are trying to achieve? 
• How does it get us closer to our product goal? 

How to create a sprint backlog

During sprint planning, developers collaborate with the Product Owner to craft the sprint backlog, which describes how they intend to deliver the increment. The sprint backlog is an actionable plan for delivery.

The developers decompose work (often expressed as user stories) into smaller items (often expressed as tasks). Tasks are small items of work that can be completed in a short timeframe (typically one or two days). 

Tasks are more precise, in detail and in scope, than user stories. When creating tasks, avoid vague statements such as ‘coding’ or ‘implementation’, thinking that you can just refer to the parent user story for the details. Instead, create meaningful descriptions of the tasks to make the scope of work very clear.

A blog by Victor Dantas offers a very good example of how to break a story down to a task level for a requirement for a web app: 

As a registered user, I want to log in with my username and password so that the system can authenticate me and I can trust it.

And with the following acceptance criteria:

“Given that I am a registered user and logged out… if I go to the login page and enter my username and password and click on Log in, then the data associated with my user should be accessible.“

By getting all the developers together in sprint planning to brainstorm on what is needed, you’re likely to hear things like:

• “We need a new UI element for Sign-up and Login”
• “We need to develop encryption functionality for the password”
• “We need to create a table in the database for user information”

Now, to do things in a more structured way, let’s ask the developers:

How can we break this down into executable, scope-bound tasks? Here, the team may agree on the following tasks for the user story:

• Define Sign-up/Login form style and develop new CSS class
• Develop HTML and Javascript Sign-Up/Login presentation layer code
• Develop Javascript sign up form validation code 

Now you can see how the sprint backlog gets formed and grows during sprint planning.  However, during sprint planning, you will not create the perfect plan. The sprint backlog is an adaptive plan by and for the developers. It is a highly visible, real-time picture of the work that the developers plan to accomplish during the sprint in order to achieve the sprint goal. 

Consequently, they will update the sprint backlog throughout the sprint as they learn more and, as such, they create, re-order, add more detail, and delete as needed. 

Sprint backlog misconceptions and anti-patterns

Developers cannot change the sprint backlog during the sprint as it is a commitment

The myth is that the sprint backlog is fixed during the sprint and that developers must implement all the work items in the sprint backlog because they have committed to deliver them. If not, the sprint is a failure. Changes to the sprint backlog are not allowed and no work can be added or removed from it, as this creates a lack of focus and there is a risk of ‘goal’ creep. 

That’s not the case. 

The sprint backlog should not be static

The sprint goal is an objective set by the Scrum team during sprint planning. The sprint goal describes what the Scrum team wants to achieve during the sprint (to test an idea, hypothesis or run a test) and how it intends to be closer to the product goal.

Remember, Scrum was created to ‘help people, teams and organizations generate value through adaptive solutions for complex problems. The Scrum team—more particularly the developers who craft the sprint backlog—cannot predict the future and create the perfect plan. Complex work is highly unpredictable, so they cannot set a detailed plan in stone during sprint planning. The developers should refine the work that needs to be done based on what they learn once work begins. 

For example, let’s assume the developers create a new feature and change several existing features during the sprint. All this needs testing, regression testing, and code refactoring, which they expected; they could not anticipate the effort and amount of work required. So, the developers will need to add work items to the sprint backlog. Nevertheless, they remain committed to the sprint goal.

The sprint backlog changes based on ‘inspect and adapt’

The sprint backlog supports empiricism—the idea that knowledge comes from experience and deciding based on what the team observes (The Scrum Guide 2020). The Daily Scrum gives developers an opportunity to inspect and adapt their progress to the sprint goal and make any adjustments to the sprint backlog. 

A metric developers can use in a Daily Scrum to help support empiricism and manage the sprint backlog is Work Item Age. Work Item Age looks at current active work (the amount of elapsed time between when a work item started and the current time). Work Item Age is a leading indicator related to unfinished work items. It is a great metric; it enables transparency to which work items are flowing well and which are stuck in the mud and not progressing as expected. Using Work Item Age in combination with cycle time can help developers to focus on those items of work which are at most risk of missing the teams’ service level expectation, and make the necessary adjustments.

The Product Owner controls the sprint backlog and therefore can pull work items in and out whenever they feel like?

If a Product Owner pulls and adds work items into the sprint backlog at will, and developers just shrug and continue working, the developers are no longer committed to the sprint goal and lack ownership of the sprint backlog that is rightfully theirs. They have just become a feature factory and no longer align with a sprint or product goal, or value creation.

Developers own the sprint backlog and must maintain accountability

The Scrum Guide states that developers are always accountable for:

• Creating a plan for the sprint—the sprint backlog
• Instilling quality by adhering to a definition of done
• Adapting their plan each day toward the sprint goal
• Holding each other accountable as professionals

The Product Owner owns the product backlog

The Product Owner is accountable for effective product backlog management, which includes:

• Developing and explicitly communicating the product goal
• Creating and clearly communicating product backlog items
• Ordering product backlog items
• Ensuring that the product backlog is transparent, visible, and understood

To learn more about the sprint backlog and other important aspects of Scrum, check out our popular FAQ, What is Agile and What is Scrum?

In a new business where a lot of things are unpredictable, a startup proof of concept can be an essential tool for validating product ideas. 

In order to make your concept thrive, you will need to calculate and define its viability and feasibility. You need insights on what you need to implement in terms of technology, finance, infrastructure, etc. to bring the idea to life. You also need to prove your concept is technically feasible and desirable to investors and other stakeholders.

That’s where you will need to develop a proof of concept (POC). Join us as we explore some of the ways to write a proof of concept and how creating it can help a startup validate its product and improve the overall chances for future investment and sustainability over time. 

What is a Proof of Concept

Before implementing any startup, there is a need for solid and undeniable proof of whether the idea will work or not. A POC or proof of principle fits in here. It helps you decide whether you can proceed with the hypothesis or not. 

Basically, a POC for a startup is a presentation of the proposed product and its potential viability. POCs describe the functionality of the product, including its general design or specific features, and how feasible they are.

A POC can prove that building the proposed solution, program, product, feature, or method is achievable. POCs further allow decision-makers, investors, and even users to explore the potential of the idea, giving them a glimpse of the bigger picture or the situation once the company launches the product.

Types of Startup Proofs of Concept

POC for a startup is a type of demonstration or prototype that shows how a new technology or business model can be implemented and tested. A POC can be either technical or business-based.

Technical POCs

Technical POCs are useful for testing new technologies, evaluating feasibility, and gauging the interest of potential customers. POC in technology can also help developers learn how to build something from scratch and identify any potential problems with their designs.

There are three main types of technical POCs:

• User Experience (UX) Proofs: UX proof is a simple demonstration that a product or service can be used by real people. This might involve testing out the design on dummy users or simulating user behavior in an analytical way.
• Product Proofs: A product proof is a more complex demonstration that the product or service can be developed and launched successfully. This might involve building a functional prototype, completing customer interviews, or conducting market research.
• Prototype Proofs: A prototype proof is the most complex type of proof of concept for a startup and requires the most time and investment to produce. It is typically an early version of the final product that has been simplified for testing purposes.

The developers at Cprime can help entrepreneurs who are looking to build a tech product to validate their idea and assess the technical requirements needed and define the tools and resources necessary to build the product.

Business POCs

Business POCs are especially important for testing new business models in the real world. They can help entrepreneurs determine whether their idea is viable, identify potential market niches and gain feedback from actual consumers. Furthermore, they can help entrepreneurs validate their assumptions about customer behavior and marketplace trends.

In many cases, both a Business and Technical POC may be needed. For example, to effectively test out a business model that revolves exclusively around a tech product. Imagine you want to launch the next Uber. You would want to put together a Business POC to establish that there’s room in the ride share market for a new contender, and that your concept is different enough to compete. But you’d also want to develop a Technical POC to ensure the app you’re envisioning is feasible.

Benefits of Validating Product Ideas With a Proof of Concept

While startups are all very different, 90% of them have one thing in common—they fail. One of the things startups can do to improve their chances of being in the 10% is to develop a POC. The benefits of a successful POC are long-lasting and can touch on every department within the startup, from product to sales.

To the untrained eye, a POC may feel like an extra step in the process, but developing one can help increase your odds of success. It can:

• Help you assess risks: Creating a startup proof of concept can help you and your team identify potential risks and issues before a product goes live. You can then decide whether to make changes to the product or go back to the drawing board.

• Get your team on the same page: Proofs of concept can help align your team and introduce them to your prospective product. For example, a POC can show your sales and marketing teams the unique selling points of your product and who your competition is. You can also use a POC to get feedback from employees who may not have been involved in developing your product.

• See if your idea can adapt and grow: A proof of concept can help you see how scalable your idea is. As an example, would it be easy to mass produce in the future? What would you do if you needed to add additional features for new markets?

• Get investors: Finally, a POC can be great to showcase to potential investors. Investors will want to see that you’ve done your research before they provide you with funding, and a POC is a great way to do this. 

How to Write a Proof of Concept

The goal of a startup proof of concept is to test the viability and feasibility of an idea. Once the startup POC has been completed, it can be used as part of the business plan in order to assess whether there’s potential for this idea to become a reality. If all goes well, then the next stage, which involves further development, can begin.

Basically, there are five essential stages of a startup proof of concept that teams can follow, from developing the idea to firming it up and presenting it to investors.

Stage 1: Conduct research and development

When you write a proof of concept, the first thing that comes into mind is Research and Development (R&D). The team needs to conduct extensive research around the history of similar work across the globe.

If there is none, the next step should be to analyze existing guides, PDFs, scholarly articles, or tutorials that would act as a key point of reference for the team.

If it is not available in the market, consider your idea to be a novel one that can mark you as a leading pioneer.

It may take time to build a POC. It may sometimes seem infeasible. But challenging the team’s technical abilities is the key here. Setting your own standards can lead to success when a business is still in the development phase.

Stage 2:  Specify the need for your idea

Once you are done with research around your idea, it is time to specify who needs it and why. Consider listing user personas your product will target and their pain points to understand their needs.

However, don’t just assume things. As you collect evidence at this stage, interview potential users and ask them questions regarding what they desire and need to solve the problem being addressed with your project. To make your proof of concept document look authentic, consider conducting in-depth interviews or online surveys.

Stage 3: Ideate the right solution

From the sample group’s answers, you can now start brainstorming with your team for the right solutions to customer pain points, keeping in mind that they should also be feasible and within the company’s capacity.

The team should then assess each brainstormed solution according to the likely costs, timeline, technologies needed, required operational capacities, competition, resources, and other factors.

Additionally, to firm up the proposal, you should discuss how your solution can support the fulfillment of the organization’s or stakeholders’ goals.

Stage 4: Create a prototype and test it

Once you have come up with a feasible idea, you should create a prototype based on the decided requirements, features, and solutions.

Your team must let the individuals in their sample group test the completed prototype so they can quickly determine whether the product truly addressed the pain points shared by the group.

Testing it with the same group enables you to document their feedback more easily, which is essential to the next step.

Stage 5: Gather and document feedback

During the prototype testing, you must gather and document the sample group’s feedback about their experience, their reactions, and any other valuable details, including what they think of the user interface.

The gathered feedback lets you initially verify the usability and feasibility of the solution. It also informs the team of any needed improvements to the proposed product and gives significant insight for other relevant actions moving forward.

Stage 6: Present POC for approval

With the concept tested and improved based on the feedback, you can now start the last proof of concept stage and prepare your presentation for the stakeholders.

You must present, among other things, the pain points that the product solves, features that address those problems, and technologies integrated to demonstrate the value of the idea.

You should elaborate on the product development and project management components, which you should also note in your project tracker.

These include clearly defined success criteria or project management metrics, evaluation measures, timelines, next project management plans, resources needed, and other aspects discussed earlier.

Once you’ve successfully presented the idea and persuaded the stakeholders to approve and invest, you can begin to implement it.

Wrap-up

Ultimately, startups looking to be a part of the successful minority need to do all they can to stand out and differentiate themselves from competitors—and that means proving their product has a market need and works on a large scale.

A POC helps startups see if a proposed idea is practical and attractive for the target market and achievable for the company. Through the business POC, you can explore the planned components and functionalities of the ideated product, along with the costs, resources, and capacities required to make it work.

In order to further increase the chance of success, startups should not question whether or not they should run a POC, but rather see how they can increase their capacity and create more POCs with more companies in more verticals in hopes of defying the odds.

The custom development experts at Cprime are well aware of the need for proof of concept. We also know how to create attractive prototypes to use for further user testing or attracting investors. Cprime developers can validate the product at the idea stage to see if it’s worth further developing and we can continue to collaborate to develop your product and launch it for success.

Ready to get started? Contact our experts to schedule a consultation.

To quickly summarize Part One of this two-part series, we are looking into the recently released Flow Metrics within the updated Scaled Agile Framework® (V6.0) which offers interesting insights into tracking and monitoring flow of work through your Agile Release Train. 

In Part One, we covered the first three of the six metrics:

• Flow Distribution
• Flow Velocity
• Flow Time 

Now, we will wrap up this series with the latter half of this collection of metrics, which will include 

• Flow Load
• Flow Efficiency
• Flow Predictability

As a refresher, many Agile concepts originated from the Toyota Manufacturing / Toyota Production System (TPS), considered to be the foundation for today’s Lean manufacturing processes. Hence, we will use this comparison to help illustrate how these metrics may map to building hardware and software solutions within an Agile Release Train.

The 6 Flow Metrics

Here’s another review of the six flow metrics that SAFe® recommends.

Continuing where we left off in Part One, we will now focus on Flow Load. 

Flow Load

If we look at the definition of this term, we realize that this seems to resemble another popular Lean-Agile concept: Work In Progress (or WIP). In a flow-based system, often referred to as a Kanban system, the WIP limit provides a throttling mechanism to minimize over-burdening the system (or the staff) by controlling the total amount of work that an individual (or a system) can perform‌ at once. 

Flow Load is essentially the same idea; by tracking the total number of work items in play, we can glean interesting insights into the health of the system. 

Using the automobile manufacturing example, the load can represent the total number of cars currently moving through the assembly line at a time, which may vary depending on the seasonality, time of the day, etc. More than likely, we are going to need to look at multiple metrics in order to make sense of the data. We will touch on that a bit later.

Flow Efficiency

The fifth metric is Flow Efficiency, which measures the amount of value-added work (or productive work) as a function of total time spent. 

Many trains struggle to track this metric because it is often difficult to distinguish good use of time versus poor use of time. For example, is “big room planning” or any other meetings that may be perceived as administrative work considered value-added work? That may be debatable. In order for this metric to have meaning in your organization, your team may need to clarify what is actually considered “value-added work”. 

Within the car manufacturing world, any idle time is non-value added work; for example, the time it requires for a technician to walk from the car to the tool bench to retrieve a tool is usually considered “travel time”, and is not value-added. Even if each trip only requires a few seconds, over ‌millions of cars, those seconds add up and will lead to lost overall productivity that can equate to significant lost revenue.

Flow Predictability

Lastly, we have Flow Predictability, which may seem familiar. The Predictability metric has been part of SAFe for several years, even if it was not specifically referred to as a “Flow” metric. 

The concept of predictability is often difficult to grasp because very few organizations are effective at tracking this metric. The ability to produce results consistently should be the goal of any Agile Release Train, and this metric will enable trains to monitor how they are doing over time.

Putting it all together

Now that we have a better understanding of each of the six flow metrics, what are we supposed to do with them? How do we know if the train is running optimally or is in serious trouble? 

In isolation, it is difficult to make a judgment on the state of the system by looking at any single metric at a point in time. We must have a reference point against which to compare in order to determine whether your train is taking on too many work items simultaneously, or not enough. This is where we need to pair the flow metrics to draw a useful and intelligent conclusion about how your train is operating.

For example, by looking at the relationship between velocity, load, and efficiency, we can put together a picture of what is going on with your train. Is the train running effectively, or is it heading for disaster? Even if you are tracking all six metrics rigorously, you will probably need to think about what “good” looks like for your specific context. To achieve this, consider the following:

1.     What does the customer truly care about?
2.     What can you do differently to move the needle on those things that are important to the customer?
3.     How can your teams use metrics to improve transparency and create a sense of purpose?

There are no right answers to these questions. You will need to think about these within your own context to decide which of the metrics make sense for you. It is possible to apply only a subset of the six metrics and still get value out of them. 

If you aren’t sure where to start, engage your train and encourage your teams to come up with their recommendations; if they are given the opportunity to define meaningful metrics, they are much more likely to provide quality data and apply them effectively.

And of course, if you need any help with this or other SAFe concepts, consider our catalog of SAFe-related learning courses and certification programs.

If you are applying SAFe® (Scaled Agile Framework®) or are considering doing so, you are most likely aware of at least some of the key updates to the V6.0 release. One of the most critical additions to this update is the concept of “flow”. 

What is Flow in SAFe 6.0?

Scaled Agile’s official definition of Flow is as follows:

“Flow is characterized by a smooth transition of work through the entire value stream with a minimum of handoffs, delays, and rework. In SAFe, we consider flow to be present when teams, trains, and the portfolio can quickly, continuously, and efficiently deliver quality products and services from trigger to value.” (© Scaled Agile, Inc.)

SAFe 6.0 provides a detailed account of the various flow concepts and metrics that you should consider when implementing SAFe. While this information is very thorough, many practitioners I work with expressed an interest in more specific examples related to how to deploy these metrics. Hence, I thought it might be worthwhile to illustrate the use of these metrics through a simple, everyday example that most of us should be able to relate to so we can gain a better understanding overall.

An example from manufacturing

Because of the level of detail that will be covered, it made sense to split this into a two-part series to ensure we provide adequate coverage of all six of the flow metrics that are recommended by SAFe 6.0. Let’s first go over the details of a fictitious project which we will use to clarify the flow concepts.

When I facilitate training sessions for my clients, I often think about a common example that is not specific to any industry or technology so that I can try to reach as many of my students as possible and help them connect to their own contexts. Although there may not seem to be a clear alignment to Agile principles and practices, I often use manufacturing concepts as a backdrop to explain Lean-Agile concepts. For this exploration of flow metrics, we will use the concepts of automobile manufacturing to clarify the ideas.

The Toyota Manufacturing / Toyota Production System (TPS) is considered the foundation for today’s Lean manufacturing processes. Hence, we will connect to SAFe’s flow metrics by inspecting how these may map to building hardware and software solutions within an Agile Release Train.

The 6 Flow Metrics

Let’s first look at the 6 Flow Metrics that SAFe recommends.

Flow Distribution

The key concept behind monitoring the distribution of different types of work is to understand how long-term and short-term objectives are being supported. For example, work may include infrastructure/enablers, sustainment/maintenance, and new capabilities/features. If one type of work is dominating the overall distribution, the risk to the overall health of the product life cycle may be elevated. 

Using an automobile manufacturing assembly as an example, the assembly line will typically contain a variety of car models that are in distinct stages of the overall assembly process. 

Within this context, we may want to see how much of the resources (human capital and technological assets) are deployed for the development of the chassis, painting, electronics, etc. 

From another perspective, at the portfolio level, it may be worthwhile to examine how funding is allocated to research and development for future car models or manufacturing of current-year models. 

By looking at the flow distribution of how work is executed for various types of work, we can assess trends (i.e. peaks, valleys, outliers, etc.) which will enable the team to make informed decisions on potential shifts in the allocation.

Flow Velocity

Using the automobile manufacturing example, flow velocity is easy to explain—it is simply the number of vehicles produced within a time horizon. For example, 1,000 cars per day, or something to that effect. In your world, depending on what type of product or service you are building, this metric may not be as simple to measure, especially if you are not shipping a physical product. However, if you are producing a service, you will probably depend on some type of technology to support that service, which I would suspect to be a digitally enabled system, in which case you can measure the number of features and/or functions that your team is deploying within a specified timeframe. That can also qualify as flow velocity.

One key thing to keep in mind is that the purpose of collecting this data is to evaluate the performance of the team in terms of productivity and efficiency. Trends will be valuable to determine whether the overall performance is improving or degrading over time.

Flow Time

In delivering products or services to the customer, nothing is more noticeable than speed; customers can often compromise on the complexity and sophistication of a solution, but they are almost always eager to receive something as quickly as possible, no matter how incomplete it might be. 

We need to keep in mind that this does not mean we can put low-quality goods into the hands of the customers and expect them to be happy. Faster delivery means we will provide a high-quality product, but possibly without all the special features that may be perceived as “nice-to-have”.

Flow time is one method of measuring how much time your team needs to put that capability into your customers’ hands. It is a trending metric that allows you to determine if your team is improving its efficiency (reduction in time), stabilizing (by a plateauing effect) or even degrading (taking more time to deliver value). 

Within the context of automobiles, flow time can be measured as the number of hours/minutes required to build a complete, functioning car that is ready to be driven.

In Part 2 of this Deep Dive, we will cover the remaining three Flow Metrics:

• Flow Load
• Flow Efficiency
• Flow Predictability

In the meantime, if you need any help with this or other SAFe concepts, consider our catalog of SAFe-related learning courses and certification programs.