BLOG

How To Maintain Focus in Agile IoT Development

Omar Antila

6 min read

‘How can we earn more points this week?’ If this is the main question that motivates your development team, they’ve probably lost their focus on user value. To regain focus, define user stories that deliver complete vertical slices of your IoT product.

What is a Vertical Slice?

A vertical slice is a cross-section of your product that includes all of the layers required to deliver a functional feature. For an agile IoT project, this includes the mechanical, electrical, firmware, and software layers.

What is Agile IoT?

Agile software development is easy to understand but difficult to master. Fortunately, we have access to many resources and frameworks, like Scrum, to organize and manage our development teams.

Things get trickier in the Internet of Things (IoT) world where simultaneously developing the hardware and software increases the complexity. A 2020 study by Beecham Research shows that 77% of team members with unsuccessful IoT projects found it a ‘very significant’ challenge to keep their projects on schedule. Most hardware development organizations still follow the Waterfall model. But, Agile IoT development, with small teams and quick iterations, is now used by more forward-thinking organizations. Rapid prototyping of IoT devices is the best way to build value fast.

However, managing these complex projects can be difficult. We recently noticed that in our effort to build value quickly, we had to overcome one of the most common pitfalls of managing product backlogs for complex work – prioritizing completed tasks over user value.

What’s the Purpose of a Product Backlog?

Be a clear and effective communication tool that helps all stakeholders understand what’s being built now and what the team will work on next.
Clearly communicate the incremental value that we build during each story from the end-user’s perspective
Maintain focus on building blocks in a user story as defined and prioritized by the product owner/manager.

The Point-Earning ‘Hack’ That Causes Teams to Lose Focus

To create tight feedback loops, we typically use short (1-2 week) sprints and build in small increments. In practice, completing features that deliver real user value across the whole mechanical, electrical, firmware, and software vertical stack within 1-2 weeks is challenging for small Agile IoT project teams.

When trying to keep sprints between 1-2 weeks, we often see too much focus on “earning points” during each sprint. Teams waste effort breaking down user stories into smaller point values so that they can be completed within the sprint period. It’s true that smaller user stories deliver value faster and with less risk, but even “good” activities have consequences if taken too far.

It’s during this story simplification that teams lose sight of the broader goals.

If the process of breaking down stories into smaller and smaller pieces continues unchecked, it results in non-user stories where different layers of the same feature are split into separate stories. For example, we’ll end up having separate “stories” for firmware and backend that don’t create any user value on their own.

While this might feel like a clever workaround to a time box constraint, it results in messy, disjointed development. The development teams begin diverging, and the product backlog becomes a loose collection of tasks. The backlog stops communicating how each story builds towards user value.

The oversimplification of user stories also makes it more likely for a team to lose focus on the big picture. Also, working in silos to complete each layer of the work reduces collaboration between our practices.

These common workarounds solve a made-up problem of “we’re not getting enough points every sprint,” and they take away from our teams’ focus on planning and building real-world value.

Write User Stories that Align the Team with User Value

Remember, a user story builds from a common goal: As a [user persona], I want to [action] so that [derived value]. An ideal user story aligns the development team with the value we’re creating together for the user. The story should be clear, concise, and as simple as possible – but no simpler. We can maintain velocity and still deliver user value with each story.

Agile development isn’t about executing perfect methodologies or muscling our development process into a framework. Agile development should make small, incremental changes that increase agility while staying focused on the highest priority: to satisfy the user by delivering value early and continuously.

Regain Team Focus by Only Building for User Value

On the whole, we need to put less emphasis on points and more on the value we deliver as a development team. To do this, we have to prioritize ruthlessly as a team. Refocus on the product strategies that we established at the beginning of the project.

1. Eliminate Any Work That Can’t Be Mapped to User Value

Eliminating work that doesn’t map to user value can seem harsh, but, as Product Managers/Owners, we own the creation of stories in the backlog. We must define the epics to prioritize the user’s perspective – their business goals, their product value proposition, and their roadmap.

2. Create Simplified Stories That Deliver Functional User Features

Simplifying user stories lets us adjust to demand quickly and helps our teams deliver features to users faster. We should work with the development team to see if and how stories can be refined and broken down. But we must stop breaking stories down before they become a fractional feature.

3. Define Subtasks and Assign Points as a Team

Define all subtasks from each practice area that are required to deliver the user story. Assign points as a team so everyone knows how their tasks build a complete vertical slice. To improve our process with agile IoT, we should focus on the cycle time of individual stories (the total time it takes to move the story from “in progress” to “done”) instead of the number of points we earn as a team.

4. Accept that Some User Stories Don’t Reduce

We may end up with a large, 21-point story that cannot break down. It’s okay to accept that it will take several weeks to complete. A story spanning multiple sprints isn’t necessarily a red flag because we understand that there’s no way to reduce the complexity of some stories.

For larger stories, we want to find ways to demo completed subtasks, so we can maintain quick feedback loops with project stakeholders. We can often do this by mocking and/or simulating layers of the vertical slices that aren’t yet completed. Once we finish the story, we’ll still earn the points and get an accurate estimate for average team velocity.

If we focus on keeping vertical slices intact but as thin as possible, they will become smaller as the system matures. If we never try to do this because it’s “too hard” in the early stages of a new product build, we will continue to struggle to understand what a “small vertical slice” looks like, because we’ve never actually built one.

Wrapping Up

Optimize for value, not points. By delivering complete vertical slices that are as thin as possible, you’ll avoid distraction and provide real incremental value with each sprint. Make sure to provide tangible user value with each story, and ruthlessly eliminate any work that you can’t map back to user value. By maintaining this focus, you’ll keep your team on track to deliver continuous value to your users.