Interactions between Product and Engineering teams

Problem

At Datto, we are a service business, so we do not publish a precise roadmap. Instead, we publish a general theme for the year for our partners and iterate towards that theme, using Scrum, and leveraging user stories instead of tech specs. We believe (as I think the Agile community also believes) that the Scrum Master is supposed to coach the PM on how to define stories that can be produced in a given time increment. In our business, a user story explains business value from the perspective of a user and defines the acceptance criteria which, if met, will achieve that value. Tech specs get into the weeds of value and implementation. We believe that the best software comes from self-organizing teams, who have the freedom to make the creative decisions they need to, to meet the acceptance criteria. User stories come from a business's objectives (the product needs to do X to achieve this competitive advantage) or from market research (the industry is demanding Y). At Datto, it is the PM's job to define how Datto's version of this value makes it to market. For example, we saw a gap in the industry for networking devices, as there were very few cloud-managed routers in the marketplace. The industry wanted the ability to manage multiple router configurations without going on-site. Datto's decided to build a router with its configuration in the cloud to meet this demand.

Actions taken

To improve collaboration between our product team and engineering team:

1. Our PMs get Certified Product Owner training, where they get a better understanding of this process.
2. The SM works with the PM regularly to craft better stories and acceptance criteria.
3. The SM, PM and team lead meet at least weekly to develop stories.
4. Lastly, we allow the team to push back. It is the PM's job to define value in the smallest increment as possible. However, there are times where that is not doable. For example, we needed to upgrade the OS on our router from an open source project, to a fork which is on the 4.4 kernel. This change provided a lot of business value but had a lot of unknowns. This couldn't have been done in a two-week sprint. So, in these types of cases, we have engineers who forge ahead of the Scrum team, do discovery, and get the build to a place where it can be brought back into the Scrum workflow.

Lessons Learned

Deadlines can not be set without iterations on the stories. The backlog is filled with defined value and gets groomed regularly. The only deadline that the PM can commit to are on the items that have been fully groomed and ordered. This is not a very long-term view of the future, so the business needs to buy into this view of the world. The key here is the business needs to buy into Agile work processes.