Adam Gonnerman

Ideally, backlog refinement should be handled primarily by the product owner with input from the tech lead. The product owner is taking direction from the business on prioritization, and the scrum master simply makes sure refinement takes place. What do you do though when stakeholders aren't in alignment on on the priorities? Here are a few steps I take when this comes up. First, I ensure there's clarity in the backlog items. We need to have well-defined user stories complete with scope and definition of ready clearly outlined. Business value, effort, and dependencies should be plainly stated.  Second, I facilitate a stakeholder discussion based on these backlog items, focusing on organizational goals and not personal preference. This means I need to frame it in terms of return on investment (ROI), risk, and dependencies. Once this is understood by all, we can move on to actual prioritization.  Third, I use a prioritization framework to draw out the relative importance of the ...

When I was being interviewed for my first startup job many years ago my resume still reflected that I had been a minister and a missionary. One of the questions that came up in the group interview was how I thought my ministry experience might benefit me in this particular role. I must have given a good response, because I got the job. In fact, I've brought to my career learnings from both ministry and English teaching (ESL/EFL).  From the world of ministry I first brought working with people toward a goal. This sometimes involved volunteer management as well, though mostly it was working with a team. In Brazil I worked with a team of Brazilians to start a church. In the United States I worked with staff and volunteers to grow the church. People management is one of those so-called "soft skills" that's essential for project management, particularly when it follows a servant leadership model.  When I got involved in Agile, and Scrum specifically, I quickly realized tha...

Some time back I heard about a young man who had graduated college with a technical degree and had gone over a year without finding a job. It's a tough market, of course, but I learned he failed to do something very important, which made it even more difficult. While he was in college he did no extracurriculars, like a computer science club, and he never actually worked. As in, he didn't do any work of any sort. He was a true full-time student with nothing else going on. That's a problem.  When I was in college my plans were very different from where I would up. My heart was set on ministry, and I took every step to prepare myself. I studied, sure, but I also went on a mission internship, did some outreach work with my college class, and supply preached practically every Sunday. I built a background in student ministry that went on my resume.  I have a friend whose daughter is following a similar path in her student career. She's studying natural sciences and has alread...

Unless you’ve seen the long version of my resume, you might not know that I’ve spent time teaching English. I never worked in public or private schools, but I did teach in language schools—both in the United States and in Brazil. In the U.S., this type of work is called English as a Second Language (ESL). Abroad, it’s referred to as English as a Foreign Language (EFL). Here’s how I got into it, what the experience was like, and what I learned along the way. Getting Started Before moving to Brazil to teach English, I took two important steps to prepare: Training: I completed a distance course in ESL/EFL teaching through The English Language Centre in London. At that time, the program was mail-based rather than online. They sent me study materials and assignments, and I responded with lesson plans and exercises. It was a traditional distance learning model, and I still have the certificate to this day. Volunteering: I spent a semester working with ESL students in a Missouri public...

One of the most rewarding parts of my work as a project manager is leading cross-functional teams from design through execution to project close. These groups bring together diverse perspectives, and my role is often that of translator and coordinator, making sure everyone is aligned and moving in the same direction. If you think about it, each function approaches a project with a different lens. Product wants to deliver user value, engineering is focused on stability, and operations is concerned with predictability. When you add in design and other functions, the perspectives become even richer. The challenge, and the opportunity, is to bring these different priorities together in a way that results in an executable plan. What I enjoy most is seeing the impact of this collaboration. When cross-functional teams work well together, the outcome is stronger than any one group could achieve on its own. It is incredibly satisfying to watch product, engineering, operations, and design combin...

Sometimes a team has tight deadlines or a heavy workload. Or both! I've encountered this in nearly every position I have held, although it wasn't usually a constant but more of a phase. For example, I worked at a startup where the team was tasked with redesigning the website and refactoring the web app at the same time. They had trouble in the past delivering consistently, so I led them through an Agile transformation as well, and they became a scrum team. This allowed us to begin to get a notion of their capacity for work. However, pressure was on to the get a large amount of work done in a very short time period. Here's how I approach the situation. First, we acknowledge reality. It doesn't do any good to pretend that the pressure isn't there. Recognizing as a team that we have a lot to do and not a lot of time to do it makes the situation clear for everyone, and relieves some of that stress of feeling like the burden is unseen. Second, I work with the product own...

Many times I have watched scrum teams ignore their historic capacity and proceed to add more work than they can possibly do to a sprint. Sometimes this is because a manager insists they include " stretch goals " in the sprint. Bad idea! Other times it's coming from the product owner who is being pressed by the business to deliver multiple features in a short time frame. This simply won't work. If you have a stable scrum team, made up of regular team members who do not switch out to other teams or work, you can determine their capacity by watching their velocity. If they commit to 100 story points of work but consistently deliver around 70 story points, then you have your capacity. The only way to increase their capacity is to increase the team size, which itself presents problems. When you add members to an established team, two things happen. First, the team overall can slow down as the new members figure things out and the team relearns how to work together. Second,...