From my talk at Milwaukee Code Camp 11/16/2019

The Powerpoint from my talk:

My notes:
Dividing work efficiently between teams is important because teams are getting bigger and so dividing work is getting more common.

Ideally each team should have no more than 7 members in order to allow for face to face communication to flourish and to allow team mates to have an intuitive sense of what the team is doing.

As teams get bigger the lines of communication increase exponentially, moving communication from being face to face to being through email or messenger applications. Even with messenger applications, this leaves people monitoring several communication rooms in order to get vital information to complete their work.

Even though we have teams of less than 7 people, we can have many teams working together. The goal is that those teams call all make progress on their portion of the application without being dependent on one another. This allows everyone to make progress and only be concerned about their own team.

Where teams need to work together, having architects in charge of development best practices, and UI/UX teams in charge of visual and interface best practices helps to ensure quality and consistency across teams.

Why break down stories?

Get whole parts done each sprint — Instead of having a story cross multiple sprints and hang out there as work in progress, having smaller parts allow us to show the remaining tasks left to complete. In agile, it allows you to show this in story points and estimate completion easier.

More efficient for the team — Having stories broken down allows people on the team to self-service pulling stories from the backlog and work on them without having to try to digest a new story by themselves.

Less roadblocks — Having too many things in one story can cause small issues to prevent a much larger story from closing. If a story describes an entire page, the color of an icon or the wording of an error message could potentially be a sticking point preventing a story that is otherwise done from being accepted. This can make it look like the team is stuck.

Demo Early– By releasing smaller parts, we’re able to demonstrate to the Product Owner or Stakeholders earlier. This means that the feedback loop is shorter and we can pivot if needed and throw less work away. Similarly, the stakeholders might want to use this to demo to the end customer, and again get information sooner.

Allows Prioritization– By breaking up stories it allows to Product Owner to see what the development team plans on doing as a work item. This allows the PO to potentially push some of the stories back or put them in the backlog if they aren’t needed and if there is a critical date for this feature to be available.