Agile, Scrum, Kanban, Lean, Hybrid. In the world of DPM, there’s no shortage of ways to go about organizing your teams, priorities and projects, and just as many tools to help you do it. Jira is becoming increasingly popular as DPMs discover its flexibility, usefulness and reporting capabilities.
David Harned, Director, PMO at Monotype, is a leading Agile thinker who wrote the book on Jira—literally. A senior PMO, executive Agile leader and enterprise agility coach, David authored Hands-On Agile Software Development with JIRA. He helps teams to harness the power of Agile and Jira.
David will be joining us as a speaker at the 2019 Digital PM Summit in Orlando this October. Looking forward to his session, “Managing Internal Projects & Agile Teams using JIRA,” we caught up with David to learn more about his background and the content of his session.
Whether you’re new to Jira, a seasoned user or just curious about the platform, David offers strategies and tips to get set up in Jira, create and prioritize your backlog, run Scrum or Kanban, broadcast team performance and examine how much value is being delivered by your program.
David Harned
From Art School to Agile Software Development
With a full alphabet of credentials after his name—PMP, CSM, CSP, CSPO, PMI-ACP—David may seem a DPM-by-destiny. But he actually started his professional journey in art, studying illustration in school and then going on to work as a graphic designer in print and web design.
Thus, it was a natural next step to start writing code and managing teams of developers. As the teams grew, so did the complexity of the systems. So David started to focus more on process—getting more done faster—and helping his team to have more fun doing it.
They began adopting Agile principles some 15 years ago, before Agile was Agile. Once David started learning about Agile, it became a natural fit for him. He’s worked with hundreds of people in dozens of Agile teams all around the world.
“I loved watching others succeed and helping that happen.” — David Harned
Getting Started with Jira
So why Jira? Jira is a cloud-based, enterprise-level application that lets you plan and track projects, ship with confidence and measure team efforts. It’s a great out-of-the-box tool for Scrum and Kanban, and integrates with Confluence, Bitbucket and hundreds of other applications.
As David says, Jira offers many beneficial features including an easy-to-use backlog and query-based boards with columns and workflows. The ability to forecast in Agile is huge, and Jira does it right out of the box with version reports that most people don’t even know are possible. In order to take full advantage of Jira, it’s important to set it up to scale.
Hands-On Agile Software Development with JIRA
So what is the best way to structure work in Jira?
Short answer, it depends. As David says, there are many different factors to consider: your team, how you work, etc. Of course, speed is of the essence. Since you want to deliver the most value in the shortest amount of time, it’s important to focus on concepts that help your team to become faster, rather than concentrating on individual goals.
In his book, David touches on strategies and tips to make this happen. From swarming to relative sizing, T-shaped people and Jira stories, David walks through some ideas to help improve how you manage your projects. Read an excerpt from his book below, and download the full excerpt PDF.
[Book Excerpt] Chapter 3: Smaller Stories and Tasks
“…What is the best way for the work to be structured in JIRA? Should we have one story per person? Should we use sub-tasks under a story to make things more specific?
The answers depend on different factors, which is one of the things that makes this so challenging. It depends on the team; it depends on how we work; and there are some key things that we need to be thinking about as we're structuring our work. Really, it's about speed. It's about delivering the most work in the amount of time that a sprint iteration is. Discussing the fastest teams, and thinking about the concepts that help teams become faster, can help us to focus on the goals of the team, and not the individual. That's one of the things that's really challenging.
We can structure our work in a way that has a story per person, but really, it's about making sure that the team is operating optimally as a team, not as a group of individuals. Swarming is a team concept that brings speed. Having the UX, development, backend development, and testers all attacking one story and moving through that one story, and then attacking the next story, is really the quickest way for the team to work, as opposed to each person working on their own thing. It helps to improve performance so that we can keep commitments realistic and get it all done.
Previously, we discussed using yesterday's weather as a barometer for how much work to commit to in a sprint. We could commit to more than that, and maybe we would complete it, but it's really about team motivation. If we commit to 10 points and we complete 12, that makes the team feel happy; if we commit to 15 and complete 12, the team feels like they didn't do a good job, and this will actually demotivate them, even if they deliver the same 12 points. We want to make sure that the team is motivated and excited about what they're doing. If we can keep the commitment realistic, it will allow the team to commit and finish the work that they committed to, and then, they can pull more from that ready queue that we created. This is really important if they're going to be delivering more than 100 percent of their commitment consistently. It will also cause the average velocity of the team to increase over time, which is a good thing.
Now, let's look at relative sizing, instead of specific sizing. If people commit to working through a story for eight hours, and then it takes ten hours, they will struggle with meeting their commitment. It is highly unlikely that someone will estimate the exact right time for the work that they need to do. Using relative sizing allows us to instead focus on the team commitment. If a story has three points, then we'll be able to relatively size that against the other stories in the sprint, so that a three-point story in one sprint is the same as a three- point story in the last sprint. We don't need to know whether that item is six and a half hours or eight and a half hours; we know that it's a three.
The last concept that you should be considering in your team is having T-shaped people. This means imagining a person with their arms outstretched to either side, so that they look like a T. They're deep in a skill set in the middle of that T, and their arms represent two other skills that they might also have. The more that we do to make our team cross- functional, the more we can increase the throughput of the team. Maybe that tester is also pretty good at process, so they can help to serve as the Scrum Master. Maybe we have a UX designer who can also do some frontend coding. This will allow us to actually increase the speed of the project when people swarm on a story, letting everyone do as much as they can. It will help us to utilize all of the team's capacity.
Let's take a look at JIRA, and how JIRA supports these ideas. We'll walk through a couple of these concepts. Moving back to our Backlog, what's important to remember is that we discussed the fact that a board shows the smallest unit of work…”
Join Us at the 2019 Digital PM Summit
Eager for more insights, inspiration and actionable tactics to improve how you and your organization approach digital projects? Join us at the 2019 Digital PM Summit, October 20–22, in Orlando, Florida.