Agile Manifesto, Ticket Estimation, and Ticket Life Cycle

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We're continuing our season where we're looking at the Agile Manifesto. And at this point, we've gone through the principles and the summary values, what we value more. And we're talking about some ways to implement the ideas that we get from the Agile Manifesto. We're talking about Scrum and have talked about the ceremonies and the roles. And I want to move into a little deeper detail and talk about tasks, essentially, or tickets, or however you want to label them. These are the things that we do within a sprint. There are a lot of ways to address these, to handle these. And usually, it is driven by the tool that the team selects. And to that extent, even how that tool has been customized or, in other words, adapted for how the team wants to work. There are a lot of tools out there, dozens, if not hundreds, maybe more of ticket type tools out there. And even if you limit it to those that are Scrum friendly, I guess we'll call it, there's still dozens and probably hundreds. Common tools that are used for this kind of stuff would include Trello, Jira, Asana, and numerous, many, many others that are out there. Most of these, if not all of them, have some level of customization. And this is where it becomes a little challenging to us. The first area I want to talk about is estimation. When we are building up our backlog and then we have tasks we have to do, and somewhere between putting the task on the board and actually working on it, we have to spend some time assessing it and estimating it. Now estimation is, I think this is the biggest challenge to software from day one, basically. If you go back and look at books like The Mythical Man Month and things of that nature, it has been written on, there are lectures about it. Generally, the issue with it is that software development is not a science. It's called computer science, but it's not a pure science. It's not something that is highly repeatable, partially because we're doing different things. Even in little ways, the tasks we do are different from the way we did them the last time. We have a different level of understanding. And so estimation is difficult because there's a bit of an artistic piece to working software. And we have discussed this before. And the way that a lot of Agile approach, a lot of sprint teams and specialists and stuff like that have addressed this is the idea of points as opposed to hours. So instead of saying it's going to take as a two-hour task as a four-hour task, what you do is you assign points to it. And there are varying ways to assign points. But essentially, maybe one is really, really easy. As you get to two or three, it starts getting a little harder. Five, six, seven, eight becomes really much more difficult. And then up to some point, there's a practical limit to it. Because if it's a task that is definitely if it's one that's bigger than a sprint, bigger than the amount of points that you can probably produce in a sprint, it needs to be broken up. You should be able to do multiple tickets per sprint and not just like if you've got a team of three. Three tickets is not a reasonable amount of tickets to get done per sprint. It should be more. And if you can't, then it could be that there's a misestimated stuff. That's one thing. But if you do that on a regular basis, your tickets need to be smaller. Typically you should have the way point values work out. I think, and I think it's probably pretty typical, is that the smallest value, you should be able to get more than one of those done a day. Probably I'd say at least two to four. So your smallest amount should at least be down to what's going to take you two to four hours and maybe more than that. So maybe even a little more granular. Not much more. You also should not be doing probably more than three to four tickets a day. If you have a really good day, maybe three or four tickets would be for one dev, sorry, per person maybe. For one dev at most, maybe they get three tickets done a day, maybe four. But you could probably go down to four, but that's even probably too granular, at least on an ongoing basis. There will be instances, but that should be a way to build, maybe in that point case, instead of breaking the ticket down, maybe you can buy in a couple of tickets. Because there's a, and the thought behind this, I guess before we move on a little bit more to that, is there is an overhead to working a ticket, to creating a ticket, to tracking it, to estimating it, to doing all of that stuff that moves the ticket through its life cycle. We don't want to have too many because then we end up, our administrative time becomes a burden. We want to keep it pretty straightforward and reasonable so that we're not spending too much time administering our process, essentially. So when we get our estimates in, and typically like I said, we should be, I personally like to limit a ticket size to, or an estimate to about a week's worth of work, regardless of what the sprint is. There will be situations where it may take more, particularly if it's like a research ticket or something like that. I may time box it bigger, but ideally it's just because of the way sprints work and things like that. That should be your outside effort as far as how you decide to break down tickets. Now it may, the time from start to end for a ticket completing may go beyond a week. I'm talking about if the developer goes heads down and works on that, if it's going to take them more than a week to get through that, then we should be able to break it down. Probably quite a bit. You should really should have most your tickets. Estimate wise and stuff like points wise, I would think it shouldn't take more than a few days. And if you get, and that's, think about it, that's not bad. If you've got a two week sprint and you do, let's say three days a ticket and you figure you probably two weeks sprints, you probably got about nine days that you're maybe implementing, then you can get three to four tickets done maybe in a sprint. That's not bad. That's probably not, it's not a lot of overhead to deal with them. It may be reasonably sized. If you need to see more, have a better idea of where you're at within a sprint, then that also helps. You may need to break it down and go a little more granular so you can, instead of big ticket items, you've got some small ticket items or small point value items that you can use to gauge your progress. If your velocity is you're cranking through a hundred points per sprint, but you've got five tickets that are 20 points each, then you're really not going to show any progress until one of those tickets get done. It's going to be very difficult to see where are we within the sprint. If it broken into say 25, and you don't have to do it, every ticket does not need to be the same size. Please don't think that I'm suggesting that, but if it averages 25 tickets at four points a piece, then you're going to have a better idea. Halfway through, you should be able to see roughly 50 points worth of work done. A quarter of the way, you should be roughly 25 points of work done. That allows you to see what your burn rate is and where you're at. That's really a key part of the estimation. It's not so much to treat it as a billing exercise, I guess, where you say, okay, you estimated four hours. Log your four hours of work in or something like that. It is more to see what do we as a team see the difficulty of these to be, assign a point value, and then over time, your goal is going to be to understand what you're, as a team, what is your sprint velocity? How many points are you typically able to address per sprint? Then because you want to get better, ideally, you're going to want to be able to start working on the ways to get more points into a sprint. This is within reason. It's not, oh, well, let's change our estimation style or extend our sprints or something like that. It's to try to make sure that you're removing obstacles so you can be as productive on those points as possible, on those estimates as possible. Another big challenge with tickets, I find, over and over again is what does the life cycle look like? It could be very simple. In some cases, it works to be very simple, where it's backlog, let's say, assigned to the sprint, queued up, being worked on, complete. Sometimes that's all it needs, and maybe that works very well. But of course, doing that, that means that's going to just how you build tickets because there are going to be things like I need to have a ticket to implement it, but I'm then probably going to have to have another ticket to do the testing because otherwise I won't have a way to signify that a ticket is ready for testing. That typically gets built into the life cycle. It's the first step, I think, and the one I probably see the most common is something along the lines of backlog, queued, in progress, ready for testing, tested or complete, or maybe ready for deployment, and then done. Basically it got deployed. It went all the way through. It got tested, and it went out in a release, released or something like that. You can definitely go much more detailed, and some teams work well with that where it's maybe something like really almost covering the steps of the software development life cycle. It could be things like first it goes in the backlog, but then there is maybe research or requirements gathering, and then design, and maybe even a design review, and then ready for development, and then actually in a development queue in progress, we'll say being implemented, and then ready to test, and then it's being tested, and then some sort of ready for deployment, and then released, something like that. You can actually go through all the steps. You can have a very complicated process. There's value in that, particularly in just being able to see how things go and to be able to move stuff through the life cycle, particularly if you've got a team that has several different sets of skills so that people can know where the tickets are that are the best suited for them, they're best suited to address. For example, if you're a user experience designer and there is a design status, then you know that here's some stuff that I need to, here's the tickets that are at a point where I need to spend some time on them doing whatever that work is. If you're a tester, here are the things that are ready to test, so I need to test them. In each of these, it can be as complicated as a ready to doing it done. You may have ready to test, in testing, testing complete, ready to design, being designed, design complete, and things like that. You may have a review status for each of those. That alone can become a challenge. It can again be a bit of a nightmare as far as administrative headache kind of thing. You want to make it functional so that the team members get something out of it, but also try to keep it from being a burden where there's just a ton of time being spent trying to maintain where things are, what's going on, and all the pieces that are a part of that. The tools will help you do that, but I think the process is almost, it probably is more important. For example, as you're going through these tickets, particularly if they have multiple people that will touch the ticket from start to end, it is important to understand or have a good process for how the data with each of those flows, the comments, the lessons learned, the notes around that ticket, things like that. That can be a pain because you want to be able to have whoever's working on it have an easy way, easy access to the information they need to get the job done. But sometimes that's been created in other steps in how you organize stuff, how you link to that information may be a challenge to read. A lot of times the best way to do it seems to be as you have a comment stream, so as people go through stuff, they'll comment or even have as part of the general detail, in this step, this was done, or here's a screenshot, or here's the lessons learned on that. You have a summary of the ticket and where it's at that is the equivalent of being able to talk to the people that worked on it and understand what they learned. What did they do and what did they learn from the time that they spent on that ticket? And then you work on them, you move them through, and eventually you get to a done state, which in itself is a little bit of a challenge because a lot of these things, all of these tools and our desire to use them extends actually beyond Sprint. So you have stuff that would be done as far as a Sprint's concerned, but it's now, as part of being done, it's actually in some sort of a customer view or user acceptance testing or going to go into some sort of release cycle, but then the release cycle may kick something back and things like that. So you may need to have some additional stuff that the team, which is okay, that the team just doesn't care about. Once it gets past a certain status, I don't even care. Some tools are even allowed to do that so that the dev team members may not even see things once they get to certain statuses. And that in itself is not a bad way to do it, is keep people so that their view, set their view into the tickets that are in this Sprint or that we're dealing with are in statuses that make sense to them, that they care about. And they can always, hopefully they can always go back and look at a ticket they worked on at some point and say, where did that end up? But other than that, day-to-day stuff, they should probably really just, they don't really need to see anything other than what their focus is for the most part. Why not gunk up their view with a lot of extra stuff that they really don't care about? I mentioned the idea, which is another challenge. I mentioned the idea of failing a test or it goes to user acceptance and it fails. In most cases, I think the best way to handle those things is that they essentially create a new ticket. If they've gotten through, if they've gone through a, what we'll call a release, if they were at some point completed. So if a test fails, if you go into your initial QA and the QA review fails a test, then in that situation, you can just basically have some way to push that back. So it gets pushed back to ready for development. The QA can say, hey, it failed. This is what went on. Maybe they have something like a tickler or something that lets that developer know that there's some work that needs to be done. They can do it and they can kick it back, move it back forward into QA again. Particularly within a testing or with a sprint cycle, this is a good way to handle testing if you can do it right. So that being, if the testing is testing stuff that's being built, implemented within that sprint. Then we talked about the idea of testing being outside of a sprint so that you would do an implementation sprint. And then how those things would progress is you implement one sprint, then you test in the next sprint. In those cases, then you may want to look at how you do it. Maybe you do want to create, you essentially say it's done from a developer point of view. It goes to testing and the tester essentially then creates bug tickets based off of that. And then it all cycles through again. But that tends to be a really long cycle turnaround for stuff. Then you get into branching and version issues and stuff like that that can be a big challenge. It takes a lot of time potentially to keep switching the context as a developer, switch the context of what are you working on so that you can get the right environment for the bug that you were working with and that you can make sure that all, you're back to where you were when you were coding it the first time and then you can make your fixes and do an apples to apples comparison. Well, that is where it really gets back to, you probably should do some level of testing, not just unit tests, but some level of QA and get that done within the same sprint so that while you're as an implementer, as a developer, dev team member, while you're in that mindset of that type of work that you're getting the feedback on it, that you're either getting, yep, it all worked or it failed QA. And if it fails QA because of some sort of integration issue, then it's essentially it's larger than just that one ticket. Maybe then, maybe it does make sense to create a ticket for it. But of course, this also goes back to the idea of if you don't complete stuff and kick it over to, you know, sign it over to QA into the last day or two of a sprint, you really have no choice but to create tickets as a QA team. Or I guess you could just, I guess you could push it back and just say, okay, this isn't going in this sprint. But then, you know, again, your turnaround time and your velocity can be greatly impacted by that. So you need to keep an eye out for how that process makes it either easier or more complex to get through a sprint and to line up some items that you've completed. It's a good stopping point for now. We're going to continue. As you see, there's a lot of, we'll call them nuances to going through sprints and how you approach stuff. And all of this is, fortunately or not, it's very much, I think, driven by your team, your environment, how you interact. What is the project type even? You know, the same team may have a very different approach from project to project, depending on what that project is and how it's implemented and how much design is needed and how much design isn't. There are a lot of facets that go into it. That being said, challenge of the week. How do you create and estimate tickets? And then, you know, sort of with that, what is the life cycle of those tickets? Does it make sense? Is it something that works for your team, you know, for you and your team, or is it somehow a burden to deal with it? And depending on what that burden is, is there something you can do either just for yourself or maybe discuss as a team how to remove that burden, how to get some of those obstacles out of the way so that your team is free to get things done as opposed to report on or talk about the things that they did? Give me something to think about, hopefully, as you go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noir podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoir.com. Just a step forward a day is still progress. So let's keep moving forward together. One more thing before you go. The Developer Noir podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, it'd be great if you go out to developernoir.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.