Light weight product ownership

7 min readMay 18, 2016

How losing some overhead weight allows the whole team to focus on what matters.

After learning from the problems faced in my previous large app development project — I wanted to validate some lighter weight Product Ownership techniques I’d been experimenting with. A smaller scale project was the perfect setting to try them in practice with less monetary risk.

Defining “light weight”

Light weight means staying efficient, using methods that are quick to create and change. It means not doing the things you don’t need to, so you have more time to focus on what is important. It does not, however, mean low quality. Sometimes on smaller Agile projects I’ve seen people forego best practices in attempts to accomplish a similar goal. I know from experience that this doesn’t work—you have to cut the right kind of overhead.

As you will see, there are a lot of things we didn’t do or make to stay efficient. We didn’t write any requirements documents, do upfront planning, kick-offs, phases, workback schedules, Gantt charts, verbose progress reporting, try to use scrum every time, or communicate through email attachments. You can probably think of a few other activities that fit in this list.

Diligent about best practices

What I did do is keep to a core of best practices.

I wrote complete user stories and acceptance criteria in “I.N.V.E.S.T”ed “vertical slices”.
We tasked and re-tasked to reflect what the story needed.
We were diligent about marking items blocked and updating the board with progress.
I maintained our Roadmap to set the right expectations.
I made sure to close the self-improvment loops with user testing and retrospectives.
Most of all, I made sure everyone always had access to me and visibility into the shared information.

Not all things have a short-cut. Some aspects are pay a little now so you don’t have to pay a lot later.

How it pays off

On the topic of “vertical slice” user stories, I made sure to do that even though it filled the board with stories that at first looked too small. It even felt awkward at the time but later in the project it paid off: we ran into several snags which ballooned the size of some of those stories. If I hadn’t kept to these practices, we would’ve had a few stories with many tasks that would have dragged on forever. Our burndown would have looked useless and at some points everything would have looked blocked.

As it was, our board and burn down remained a very good reflection of the work taking place and what needed to be escalated. This allowed our primary stakeholder to pivot and adapt right along with us, as we discovered it. We were able to keep delivering the majority of stories on schedule and improve ourselves in the process.

Step 1: Gather primary stakeholder info

This app was one that had a simple tile hub to detail screen navigation structure and we’d already received an email outlining and initial set of tile titles. So what I needed to do first was to pin down the specific tile/detail combinations we need to build and how they might best be ordered. Since I had easy access to meet our client (primary stakeholder) in person, we conducted a short feature mapping session with stickies on a conference room wall. I made this quicker by writing some of the stickies before the session.

After that session I took the stickies back with me and put them up in the same arrangement on one of our office walls, before using them to create stories and epics in an online kanban board.

Step 2: Decide on Agile framework and info radiator

The common choices for app development projects are Scrum, Kanaban, and XP. The timeline, budget, and scale of this project lent itself most to Kanban. Anything else would have meant more overhead or didn’t apply to our situation.

Our previous large project had teams in different time zones. We’d been trying to use and maintain a physical board primarily for the main office and TFS for the remote members. It was a full time job just updating one and reflecting changes in the other, so the board on the wall no longer made sense and the online tracker had to change.

We had been assessing several tools for tracking projects and found we were most happy with the idea of using Trello with Chrome extensions like Burndown for Trello. Other popular options like Rally, Jira, Pivotal, and the TFS we’d been using had too much overhead of various kinds for simply creating and moving user stories. In Trello I was able to quickly set up a compact Kanban board with the following key elements. In this image, the board is taken from a project endpoint and the burndown is from part way through. That is why nothing is populating the Backlog or the “working on it” columns and the Roadmap dates have all passed (view full size):

Step 3: Transparency for less overhead

As soon as I got enough of the stories defined, I opened the board up to our primary stakeholder so she could both view and participate with the cards and burndown at her convenience. She and I even shared a column on the board (separate from the dev backlog) that we populated with tasks we needed to complete along with the development stories. We all knew what each other were working on by looking at the same board.

Next I chose to design (as I both Design and Own for this project) most of the interface in a browser based tool called Moqups that allows for an equal amount of open collaboration as the kanban board — with all participants.

Finally I scheduled feature demonstrations to include our primary stakeholder. We weren’t as able to meet in person later on, so these happened over screenshare and I would follow demos up with a video of the current screen recordings for large and mobile target devices.

Step 4: Internal and external user testing

In order to maximize our end user quality we conducted two rounds of user testing. The first was an internal with a handful of employees not familiar with the project and the second was a small set of beta users from the actual target audience for our client. In the internal round everyone was added to the board and entered their bugs directly into Trello.

It was quick and fruitful, catching most issues in less than an hour. After some issues were fixed for a private Store url beta release, our beta users had a turn and found issues more specific to their perspective. We capped their review time to a few days and integrated their enhancement notes into the following release priorities.

Another example of quick, easy user testing catching problems early.

Step 5: Keep the line open

Minimizing meetings and maximizing collaboration was another thing I wanted to push further with this project. I was strict with timeboxing every standup, demonstration, and anything that could mutate into being called a “meeting”. Working sessions however are different. Being PO, I need to be available to everyone during all core hours. The most can get done with speed and quality whenever we do work together that depends on one another to complete. Two examples from a previous project:

There was a big deadline we couldn’t miss and too much to do, staying late all local people in the same conference room, remote people on an open line, and an ad-hoc mini-kanban board on the wall for every item to be addressed that evening. Apart from staying late (since working too long reduces your level of quality), it was the first powerhouse working session that team had done together and we completed an astonishing amount of work compared to the previous sprint (that project was using scrum).
On the heels of that evening, I pressed for more of that during normal working hours. Where historically people start scheduling meetings, I just scheduled “keep the line open” hours so that any time anyone remote had a reason to speak to us, they’d just unmute (if muted) and talk.

How that worked in this project was just working in the same fashion we had with non-remote team members: either working in the same room with at least one ear non-headphoned or pairing in some fashion. A lot better collaboration can happen when there are less barriers to do so, however small they might seem.