Episode 48: Agile Practices: Backlog

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO at QualityNet. And today we're in the fourth, last chapter of our enormous agile software development. Series here on the bottom up skills podcast. And today's topic is the backlog. Now this little old thing kind of matters.

Yeah. In an agile project. Um, a backlog is the, really the foundation of what everybody comes back to, to work out some important things. Uh, number one what's most, it was important in terms of the work that we are. Making right now could be design development. Wireframes user stories. This is really the essential piece, the [00:01:00] backlog, and as each individual in the team should know what.

They are working on right now and the backlog is the source of this. So what we're going to do is we're going to talk a little bit about the backlog and we're going to discuss how to get the right stuff in there, how to get the right details in there. And ironically, although a lot of people focus on the backlog for their current sprint, really.

The best practice with a backlog is to be actually looking at it, uh, in terms of what's after the sprint you're working in. So looking ahead and, and really this idea of being at least one or two steps ahead. So we're going to get into all of that as we talk about some of the best practices in agile and scrum.

All right. So there's little old backlog now. Um, if you're trying to visualize what this might look like, it's, it's simply just a list of work [00:02:00] of the key pieces of a product. And if you've been listening to this series, you'll obviously know that we're quite fond of JIRA and confluence at Colton. So you might want to check out those products.

Uh, designed and developed by a fabulous Australian company too. I might add. And, um, it's there that you'll be able to manage your product backlog and, um, I want you to, um, visualize a very rich task or that's ranked in order of priority. That's really, uh, At its simplest form. That's what it is. But if the right attention and the right effort is put into each and every one of these, so user stories, epics, and themes, then this is a really powerful tool because a whole bunch of cool things happen.

First of all, if you use a product like JIRA, you'll actually see from [00:03:00] sprint to sprint how good you are at getting those two dues done. And it gives you this information that will help you judge better. How to predict your time for subsequent sprints as well. So, you know, the, the key thing. When you think about your backlog is this list must be not only managed by your scrum master.

Everyone must be contributing because then the data is rich, then it's relevant. It's got context and it helps you when you've got a question, uh, about something in the backlog, then the requirements and the attachments and the rich data. It is listed inside of it. Can tell that story. I think a really good, uh, check.

For a backlog is if the backlog has been a bit neglected, the node of write-ups inside each of the user stories or each of the issues, um, you're going to [00:04:00] actually find that the information is not enough. And then the worst thing in the world happens. You have to send an email, you have to like get someone on text or give them a call and say, Hey.

You say that we have to do this right now, but there's not enough information, so I'm not able to meet. So if you have a backlog, I put time and effort and attention. Towards it, and it will serve you very well because everyone will know what matters. What's the biggest priorities right now. And here's the critical thing that we'll know what they're meant to be doing now.

And that means less clarification conversations about who's doing what. So as we talking about clog, uh, I'm just thinking about all of the things that I've seen in projects. And I think if I reflect on, uh, the three best pieces of advice that I can give to you about using a backlog, it's the following three, I think you [00:05:00] need to groom it.

I think you need to, uh, have high attention to the details. And I think you need to be planning already, at least one, if not two or three sprints ahead. So I'm going to dig into each of those now, but grooming devil in the details and working several sprints ahead. This is at the essence of the best practices of using a backlog in an agile software development project.

Alright, grooming. You know, for me, this is really interesting. We're not talking about going to the barbers. We're actually talking about software here, but what we need to do is get together and to really remind ourselves of what is really important for this product now. What's really, uh, fascinating here is how often teams find themselves working on things that are not the highest priority and in an [00:06:00] agile software development project.

The thing that matters the most is a working product. And the thing that matters the most within that is the essential. Feature Epic theme or user story, whatever the killer app is in your product. You start there, you don't start with the login. You don't start with privacy and disclaimer, you don't start that any of those, cause they're really straightforward.

It's all about knowing what is number one on your priority list. And that's what the grooming sessions should do. You should be getting together as a team and collaboratively talking about and evaluating together. What's essential in this product and therefore organizing the backlog, all the issues in the backlog, you organize them accordingly.

So pay attention to make sure that you are focused on grooming towards working code. And secondly, making sure that it's the essential features that are working, you know, [00:07:00] as I said, you know, logging in and all those secondary pages FAQ. Those things are not tricky. Focus on the complex things that add the most value.

And that's a great way to start grooming your backlog. Now, the next thing that I mentioned is details and, uh, When you start you're, you're, you're going to add a bunch of, uh, issues and user stories and epics and themes and all that good stuff into something like JIRA. And there'll be a bunch of write-ups and something like confluence, which will give a broader, uh, more Wiki or Google docs kind of context behind what's in the backlog.

But. The really important thing here is make sure that the issues inside of the backlog, these are the individual items that make up the backlog, make sure they're written written up. Well, I mean the classic thing not to do is just to have the heading a [00:08:00] title of the issue and then you open it up and it's blank inside.

That's no use to anyone. So take time to make sure that the requirements are written up that may be attaching or linking. Relevant documentation. And I, and I said this earlier in the show, just make sure that a third person who came to this, let's say it's something for a developer that they could read this issue or user story.

And there is sufficient information for them to actually begin their work. If it's insufficient. You'll know because they have to call you and say, Hey, I don't understand. Where are those things that you mentioned? Uh, I don't understand why I would do it like that. And then that is the classic moment where, you know, the issue is not written up completely.

So make sure you take the time to put the detail into it. On the bigger projects you might find a business analyst writes this on really big projects. The business analyst and the product [00:09:00] owner will be. Always, always reviewing, editing, adding, and revising their...