Development teams always have plenty of work to do. Requests come from every direction, with all facets of the business requesting assistance with their projects. How does a team go about parsing, filtering, distilling, and prioritizing all of those requests into something actionable? A Scrum team typically consists of a Product owner, a Scrum Master, and anywhere from 3-9 team members. Each member of the team has a defined role to play, whether it is the Scrum Master that needs to clear roadblocks, or the Product Owner that needs to prioritize and coordinate with others outside the team. In an ideal scenario, the Product Owner will have just enough in the backlog to keep pace with the team. This is rarely the case, though, especially if the team is serving internal customers (in which case the members of the team play their different roles, but emphasis is placed on an additional facilitator).
The Analyst
One of the absolute key members of a Scrum team is a business analyst. Unless you are very lucky, your business stakeholders will rarely come to you with a list of “Ability to…” stories. The Business Analyst role is key to helping the stakeholder develop a set of requests that can be prioritized in the queue. Many times, this also requires the Analyst help the business team to understand and document their own process, as it is currently being used. This is especially true in smaller organizations. Without a defined operational process, business processes may go on a meandering path, grow stale, or exist in a single person’s head. This is an opportunity to examine what the current process is, refine it, and then make a constructive request for assistance to the Scrum team to improve it. The Analyst can be of great assistance to the next role.
A request for development resources is like mapping a coastline — the closer you look, the more detail you’ll find.
Product Owner
The Product Owner gets the lucky job of drinking from our titular firehose. This individual needs to have the ability to take the flood of requests and information and parse it into something the team can consume. Teams can be easily overwhelmed by too many competing priorities, or the frustration of being pulled in too many different directions. The Product Owner can take the now consumable request of stories from the Analyst and combine those with input from leadership, feedback forums, and user input. The special Product Owner magic comes in when all of these sources are taken together to create a shortened backlog the team can review during sprint planning. By-the-book sprint planning would require review of every story in the backlog, but this typically leads to frustration over the amount of work to do and a sense of being overwhelmed by the Scrum team. There will always be more stories, but the Product Owner can play a key role in decreasing the pressure from the firehose to help the team accomplish meaningful work. Ultimately, you want the team to deliver noticeable and worthwhile value to the customer.
Less Whack-A-Mole, and fewer hydras.
Scrum Owner
The Business Analyst works on translating business muscle memory into epics and stories. The Product Owner provides political insulation and vision to the scrum team. Then, the Scrum Owner clears the path for the team to be productive and successful. Scrum is defined in phases, or sprints. If the team doesn’t produce results that are seen, this can significantly hamper future outcomes. Team momentum is also disrupted by technical debt (time spent working on fixing past mistakes rather than delivering value to the customer). Being able to focus as a team, work in an iterative way, and produce well-received output all lead to continuously improving outcomes. Success is predicated on good input. As technology professionals, we tend to be very good linear thinkers and problem solvers, and this can be a skillset lacking in other areas of the organization. By assisting, we can demonstrate a willingness to participate in broadly benefiting the whole, and change some of the misperceptions about our chosen profession.
Eric Jeanes is a recovering systems administrator with a passion for cloud tools and services. He likes people, but thinks organizations are more interesting. He currently develops cloud technologies for Internet2, a higher education community organization, and he can be found on Twitter @emjeanes.
