summarize below meeting transcript.

0:0:0.0 --> 0:0:7.380
Will Lytle
There we go through some example use cases or you know different perspectives and ways of using the data.
0:0:9.550 --> 0:0:18.230
Will Lytle
So I think it's we're going through this today, it would be very good if this is a kind of collaborative effort, collaborative conversation.
0:0:18.240 --> 0:0:21.380
Will Lytle
So if you do have any questions, please raise your hand.
0:0:22.990 --> 0:0:31.60
Will Lytle
Also, if there's any potential use cases that you have or challenges that you have, those always gonna be far more interesting because we can actually use your data.
0:0:31.70 --> 0:0:38.120
Will Lytle
Sometimes it's very difficult for me to illustrate a use case when the data doesn't necessarily marry up to that use case.
0:0:38.470 --> 0:0:40.740
Will Lytle
So they'll have to be a little bit of suspension of disbelief.
0:0:40.750 --> 0:0:53.630
Will Lytle
I guess today was we go through some of this because obviously we'll be looking at your data and I can't always curate the problem that I'm necessarily trying to to evidence as a potential use case for Plandek or the data behind you know what might lead to these decisions.
0:0:53.640 --> 0:1:4.250
Will Lytle
So if there are any like real life examples that will just make the conversation today, I think a little bit more, more relevant or at least have some evidence backed data for us to be able to take a look at.
0:1:4.970 --> 0:1:7.780
Will Lytle
I'm feel free to use the chat as well.
0:1:7.930 --> 0:1:14.200
Will Lytle
I'll try to keep an eye on the chat as quickly as closely as I can throughout this and we will.
0:1:14.510 --> 0:1:16.560
Will Lytle
We'll pick up any of those questions as we go along.
0:1:16.810 --> 0:1:17.490
Will Lytle
So that sounds good.
0:1:19.360 --> 0:1:19.800
Speaker 1
Yep.
0:1:19.980 --> 0:1:24.590
Speaker 1
Yeah, I will monitor it to chat as well and and inform you as any question.
0:1:25.960 --> 0:1:27.690
Will Lytle
Alright, OK.
0:1:27.700 --> 0:1:44.430
Will Lytle
So, umm, inevitably I'm going to have to pick a space, so we're going to pick the emergent PR space, so apologies in advance if this is your space and and and we're gonna use your data today as a Guinea pig.
0:1:46.470 --> 0:1:58.60
Will Lytle
What I wanted to do is pick, I think a couple of the real common metrics that we see a lot of across a lot of our clients and just talk through some of the different ways in which people are looking at this data, how they're using this data.
0:1:58.70 --> 0:2:5.960
Will Lytle
Some of the insights that might pop up into this data that might be relevant to you, it might not be, but please, you know, feel free to ask along the way.
0:2:7.30 --> 0:2:23.470
Will Lytle
I wanted to start with print Sprint predictability because I think from a, you know from a getting started perspective, this is probably one of the metrics which I think has you know it's easiest to to understand what's going on here.
0:2:23.480 --> 0:2:28.350
Will Lytle
And it's also, I think, relevant and useful for the majority of teams, at least those teams.
0:2:28.360 --> 0:2:29.670
Will Lytle
Obviously they're doing Scrum.
0:2:29.680 --> 0:2:31.90
Will Lytle
If you're a Cadman team, we will.
0:2:31.180 --> 0:2:51.370
Will Lytle
We will talk a little bit about Kanban metrics today, but we'll start with Scrum just because the largest proportion of teams are so Sprint predictability is, you know, at the end of the day it's about driving a very simple behavior, which is the ability for a team to consistently plan and execute right plan.
0:2:51.380 --> 0:2:57.570
Will Lytle
Meaning we understand what our capacity is, what our potential velocity is, right?
0:2:57.640 --> 0:3:0.210
Will Lytle
We can effectively plan against that, right?
0:3:0.220 --> 0:3:8.820
Will Lytle
We can identify what are the goals we want to achieve this Sprint and therefore what are the tickets that we need to put into this Sprint to be successful in accomplishing that.
0:3:10.300 --> 0:3:17.500
Will Lytle
The emergent team here is is, you know, fairly successful, I would say in this point with a lot of clients.
0:3:17.770 --> 0:3:28.410
Will Lytle
We always suggest that teams are aiming between 80 to 90% AH and you don't want to really be much less much.
0:3:28.980 --> 0:3:37.750
Will Lytle
You know further below 80% because ultimately that then statistically starts to impact the ability for the team to plan on what to execute on what they planned on.
0:3:37.800 --> 0:3:49.590
Will Lytle
So if you're working in a a quarterly road map and that quarter is based on a series of, let's say fate sprints or whatever, it might be 6 sprints.
0:3:51.140 --> 0:3:54.890
Will Lytle
You wanna make sure that each one of those sprints are orchestrated correctly?
0:3:55.920 --> 0:4:13.810
Will Lytle
If you wanna be able to kind of make it to the end of that that quarter having achieve most most of what you have counted what you said out to accomplish and I say most because I don't think agile and necessarily is best applied when trying to deliver a full scope of 100% of things over 1/4.
0:4:13.880 --> 0:4:30.470
Will Lytle
They're probably different methods that you could use that will be a little bit more effective at delivering a fixed scope or for a fixed time I waterfall, but when you are looking to be able to delivered to a target with a little food ability, it's quite an effective way of doing that.
0:4:30.620 --> 0:4:46.240
Will Lytle
Now obviously, if you go above 90% then the question is ultimately in the if we're able to achieve 95 to 100% of what we planned every Sprint and we're dealing with some level of acceptance scope change, cause priorities will change.
0:4:46.250 --> 0:4:53.140
Will Lytle
There will be things that get reprioritized because they must be reprioritized, there might be a production incident that pops up that needs to be dealt with.
0:4:55.80 --> 0:5:3.570
Will Lytle
You really don't wanna be accomplishing 100% and also accounting for those things because then it probably suggests that you're really under planning based on your capacity.
0:5:3.580 --> 0:5:11.150
Will Lytle
So you wanna set you wanna set the goal of the team is to accomplish a number of goals and a number of tickets that really deliver those goals.
0:5:11.500 --> 0:5:17.370
Will Lytle
But be realistic about the fact that because of the process we're taking, 100% isn't actually the right goal post.
0:5:17.380 --> 0:5:19.220
Will Lytle
It should probably be somewhere between 8:00 and 90%.
0:5:20.800 --> 0:5:22.510
Will Lytle
So why does this metric matter?
0:5:22.980 --> 0:5:23.590
Will Lytle
OK.
0:5:23.900 --> 0:5:32.720
Will Lytle
Well, number one is in the top left age, your velocity and you can toggle between whether you want to measure the velocity with story points or tickets.
0:5:34.910 --> 0:5:36.710
Will Lytle
That should be a very simple option here.
0:5:36.780 --> 0:5:38.810
Will Lytle
How you want this to be to be calculated?
0:5:39.160 --> 0:5:49.390
Will Lytle
The reason I put tickets and I think the reason why I tickets is most meaningful for most teams, is most teams don't story point things like a subtask or they don't.
0:5:49.400 --> 0:6:2.90
Will Lytle
Sorry, point their bugs or defects or support tickets or you know a lot of teams focus on story pointing things like stories or potentially bugs that are in a backlog that are not related directly to the story.
0:6:2.100 --> 0:6:4.610
Will Lytle
So what you guys call a story bug in this instance, right?
0:6:6.580 --> 0:6:18.110
Will Lytle
And so if you use story points as the calculation for this, mathematically you will not be calculating the things that aren't story point, and you'll only be your numerator and your denominator is basically based on story points.
0:6:18.300 --> 0:6:28.30
Will Lytle
And so whilst it's a meaningful view, if you're really wanting to focus on what proportion of the kind of new value that we're delivering in terms of story points is being put, then that's fine.
0:6:28.250 --> 0:6:33.690
Will Lytle
But if you're trying to get a full picture, then I think the tickets provide a more representative view now.
0:6:35.590 --> 0:6:45.940
Will Lytle
I think more important than the velocity is really the volatility because what this volatility does is it basically manages or looks at the standard deviation for your team.
0:6:46.70 --> 0:6:48.660
Will Lytle
So you can actually show what are the sprints.
0:6:48.670 --> 0:6:54.180
Will Lytle
We're taking a look at what is the simple standard deviation of that and how that's calculated right.
0:6:54.220 --> 0:7:2.700
Will Lytle
So you can see the volatility calculation here to give you a little bit of an understanding of what the hell is 52 meters, what is 53 mean and what is 53 mean here.
0:7:2.850 --> 0:7:15.300
Will Lytle
So this is showing you that currently based on the last five sprints, the volatility of 52, if we look to the last Sprint based on the five sprints prior to that, right, it would be 53 and 53.
0:7:15.310 --> 0:7:17.980
Will Lytle
So you can see that there is a trend here, right?
0:7:18.20 --> 0:7:23.60
Will Lytle
And the reason this is so important is because you're velocity is one thing, right?
0:7:23.70 --> 0:7:41.930
Will Lytle
But if you're calling trying to use your velocity to get some sort of an understanding in a future view of you know, how much can we deliver over the next 5 sprints for Pi, the volatility is gonna be quite important because it adds a low level of confidence behind whether or not 8 tickets is something credible or whether or not that's going to be highly variant.
0:7:41.990 --> 0:7:51.920
Will Lytle
Now, this one in particular here is impacted quite significantly by this Sprint, which will go into in a second, cause there's something that happened in this Sprint which I think is important.
0:7:54.290 --> 0:8:4.980
Will Lytle
But otherwise, I would argue that between eight, 11810 and 11, there actually is a reasonable volatility there.
0:8:5.250 --> 0:8:12.920
Will Lytle
OK, now this calculation here at the moment is based on what was included the start of the Sprint.
0:8:13.340 --> 0:8:13.710
Will Lytle
OK.
0:8:13.720 --> 0:8:19.410
Will Lytle
So when we say velocity it's I want the velocity, the things that we did we completed before the end of the Sprint.
0:8:19.460 --> 0:8:26.410
Will Lytle
I want that to be based on only the tickets that were planned before the Sprint started, right in terms of commitment.
0:8:26.420 --> 0:8:32.80
Will Lytle
What we said we were going to do, I want that to equally be based on only the tickets that were included.
0:8:32.90 --> 0:8:33.210
Will Lytle
The start of the Sprint.
0:8:33.840 --> 0:8:55.350
Will Lytle
The reason this is often used as a default, and again I think there's a there's value in looking at it both ways is ultimately what you're trying to drive long term is at a level of maturity that we can plan and execute before we hit start in the Sprint right that we with a high level of confidence we can identify what our goals are for this Sprint.
0:8:55.400 --> 0:9:2.40
Will Lytle
We can identify the tickets that we need to deliver to deliver those goals, and therefore this is a good starting point for us to be able to measure it.
0:9:2.600 --> 0:9:14.330
Will Lytle
That said, if you are a team that's equally dealing with things coming in and out of the Sprint, you could also bubble this to look at anything that was ever included in the Sprint.
0:9:14.340 --> 0:9:22.870
Will Lytle
So whether something was added to the Sprint or was planned at the start of the Sprint right, you can now have the calculation based on that.
0:9:22.980 --> 0:9:30.110
Will Lytle
Now you still see a little bit of an impact here and I I can't tell you the context about what happened here and I don't think it's important for today's conversation.
0:9:30.940 --> 0:9:31.820
Will Lytle
Obviously there is.
0:9:32.820 --> 0:9:33.290
Will Lytle
I'm on.
0:9:33.300 --> 0:9:35.500
Will Lytle
We looked at it was planned before the Sprint started.
0:9:35.510 --> 0:9:38.740
Will Lytle
It was a low number of tickets and then this Sprint.
0:9:39.790 --> 0:9:42.490
Will Lytle
Umm, obviously had a few tickets added into it.
0:9:43.210 --> 0:9:43.550
Will Lytle
Umm.
0:9:43.690 --> 0:9:45.870
Will Lytle
And to those tickets were completed by the end of the Sprint.
0:9:45.880 --> 0:9:56.100
Will Lytle
Now there could be a number of reasons for that could be maybe the, maybe the team had something else planned, they were supporting a production release, or maybe there were a number of people on the team who got sick that week.
0:9:56.110 --> 0:9:56.980
Will Lytle
And that's just an anomaly.
0:9:57.260 --> 0:9:57.820
Will Lytle
That's fine.
0:9:57.830 --> 0:10:6.320
Will Lytle
Like you know, you would expect things like this to happen from time to time in the data point being here is that allows you to get both views of these things.
0:10:6.330 --> 0:10:18.120
Will Lytle
Now obviously this Sprint completion takes a hit there when we drop and the reason being of course is given the fact that tickets are being added into the sprints which will come into in a second.
0:10:18.190 --> 0:10:21.480
Will Lytle
But it's gonna naturally change what the completion rate is, OK.
0:10:23.180 --> 0:10:27.450
Will Lytle
So I'm gonna go back to this view here just very quickly now.
0:10:27.540 --> 0:10:39.570
Will Lytle
If you look at what was planned at the start of the Sprint and what was what was included, the start of the Sprint versus what was committed based on what was started, the Sprint doesn't mean that all of your data is completely obfuscated.
0:10:39.800 --> 0:10:42.820
Will Lytle
OK, this is where the committed versus completed view is really helpful.
0:10:43.930 --> 0:10:48.840
Will Lytle
And with this view here basically looks at everything you're you're full composition of the Sprint.
0:10:49.270 --> 0:10:52.900
Will Lytle
OK, the blue bar is always going to be based on what you committed to.
0:10:52.910 --> 0:11:1.850
Will Lytle
These are things that entered into the Sprint, whether it happened before the Sprint started or after the Sprint started, and it helps you get an understanding of a couple of different things.
0:11:1.960 --> 0:11:4.150
Will Lytle
One is carryover, right?
0:11:4.160 --> 0:11:8.30
Will Lytle
I I would argue that this team is reasonably healthy with carryover.
0:11:8.80 --> 0:11:20.210
Will Lytle
I've seen teams that are a much higher than 17%, but what the carryover represents is that there is a ticket that was in our previous Sprint that was not completed and that ticket was immediately carried over into the next Sprint.
0:11:20.480 --> 0:11:31.620
Will Lytle
So if you think about this in some ways, you might say that 17% of your velocity over time is going to be cannibalized by work that we weren't unfortunately able to get done in the prior Sprint.
0:11:32.170 --> 0:11:36.560
Will Lytle
Now again, we don't expect Sprint completion to be 100%, right.
0:11:36.850 --> 0:11:42.240
Will Lytle
We do expect there to maybe always be a little bit of carryover and that's why I'm not too worried in this instance.
0:11:42.570 --> 0:11:43.630
Will Lytle
You know why 17?
0:11:43.710 --> 0:11:45.670
Will Lytle
This is 17%. OK, fine.
0:11:45.680 --> 0:12:7.600
Will Lytle
I mean, there's going to be spillover between sprints where this starts to make people nervous is when it gets above 20 percent, 30%, because that starts to mean you're actually really having a kind of statistical cannibalization of your velocity on an ongoing basis and that's something you can you can hit the you can take a hit with one Sprint, but you certainly wouldn't want to see that over time.
0:12:8.210 --> 0:12:17.340
Will Lytle
And that's where these views here can be quite helpful, because this helps you distinguish of what we plan for a Sprint, how much of it was new work that we planned right.
0:12:17.350 --> 0:12:23.390
Will Lytle
So you can see roughly 50%, just over 50% was new work planned for this Sprint.
0:12:23.660 --> 0:12:24.930
Will Lytle
A number of it was carried over.
0:12:24.940 --> 0:12:33.30
Will Lytle
Unfortunately, nothing was added as part of this Sprint, but in the next Sprint we had a couple of tickets that were carried over and a couple of tickets that were added mid Sprint.
0:12:33.220 --> 0:12:40.390
Will Lytle
So it allows us as a team to really be able to kind of dissect over time what's happening with our data, what's happening with our planning activities.
0:12:40.820 --> 0:12:44.330
Will Lytle
Generally speaking, I think this team shows very good patterns right?
0:12:44.340 --> 0:12:52.500
Will Lytle
The Farr majority of the work that's going into every Sprint, both from a plant as well as a completed perspective, is based on planned work, right?
0:12:52.690 --> 0:12:58.960
Will Lytle
And you have an acceptable threshold of, you know, work being added now, you'll probably have.
0:12:58.970 --> 0:13:0.30
Will Lytle
What are these thresholds?
0:13:0.40 --> 0:13:0.410
Will Lytle
I don't.
0:13:0.420 --> 0:13:5.460
Will Lytle
I don't think there's a benchmark threshold that you can apply for all teams in all situations.
0:13:5.470 --> 0:13:17.980
Will Lytle
I think the team, when you're looking at this data, you have to be, you have to kind of understand what you're comfortable with is thresholds that's going to allow you to ultimately to be able to maintain a healthy completion right here, OK.
0:13:20.190 --> 0:13:34.650
Will Lytle
That sounds like a bit of a cop out, but I think the important bit is is a team has to draw, has to have a real kind of proximity and understanding to their own data and the thresholds that will allow them ultimately to to maintain the healthy completion rate.
0:13:34.660 --> 0:13:37.350
Will Lytle
And some of that might be influenced by carryover.
0:13:37.360 --> 0:13:39.240
Will Lytle
Some of it might be influenced by ticket change.
0:13:40.460 --> 0:13:42.220
Will Lytle
The ticket change will come into in a second here.
0:13:42.660 --> 0:13:51.630
Will Lytle
I'm but that that's where my view is on the on thing now in terms of the ticket change, there are two kind of views on that and try not to make this about training.
0:13:51.640 --> 0:13:54.660
Will Lytle
But I think in everybody part of it is about training as we walk through some of these.
0:13:55.630 --> 0:14:2.80
Will Lytle
So the scope change will help you get a sense of what's added and removed from a particular Sprint, right?
0:14:2.90 --> 0:14:3.780
Will Lytle
So we don't see anything actually being removed.
0:14:3.790 --> 0:14:13.80
Will Lytle
What we would expect to see here if there was work being removed is that you'd have a little orange bar below this purple bar, so the purple bar allows you to see the tickets being added each Sprint.
0:14:13.190 --> 0:14:18.160
Will Lytle
So we talked a little bit about the Sprint already, but you can see that there's a little bit being added every Sprint.
0:14:18.170 --> 0:14:21.740
Will Lytle
And again, that's natural and if you want to, you can click in here.
0:14:21.950 --> 0:14:22.820
Will Lytle
See what it is.
0:14:22.970 --> 0:14:25.500
Will Lytle
It's unsurprising that a bug gets added to a Sprint right?
0:14:25.510 --> 0:14:29.230
Will Lytle
You would typically expect things like bugs to be added to sprints OK.
0:14:31.950 --> 0:14:33.100
Will Lytle
But what does that mean?
0:14:33.210 --> 0:14:34.130
Will Lytle
Like what is, what is?
0:14:34.140 --> 0:14:36.860
Will Lytle
What does that change mean in the context of everything else?
0:14:36.900 --> 0:14:41.500
Will Lytle
So the scope change percentage basically takes into consideration.
0:14:41.570 --> 0:14:45.500
Will Lytle
So this will show you your gross as in we added we added six but we removed 6.
0:14:45.510 --> 0:14:49.160
Will Lytle
So essentially, we maintained a 0% change, right?
0:14:51.860 --> 0:14:57.340
Will Lytle
This will show you what you originally had, what you finished with it, what the gross change was, and what the net change was.
0:14:58.180 --> 0:15:5.310
Will Lytle
The second view here in terms of the scope change itself will put that in proportion of the overall scope of the team.
0:15:5.740 --> 0:15:12.240
Will Lytle
So what it basically means is 35% of that team Sprint scope changed during the course of this.
0:15:12.340 --> 0:15:23.110
Will Lytle
So serves a relative view so that you can see, you know, OK, well, maybe we had a lot of tickets added, but the proportionally it was actually a very small level of change as opposed to in this example, more tickets added.
0:15:23.120 --> 0:15:34.930
Will Lytle
Actually, a third of our scope changed in this, so that might have an impact as to whether or not, for instance 105, umm, you know, arguably the team did quite well to navigate through that phase.
0:15:35.160 --> 0:15:40.490
Will Lytle
OK, so a lot of our clients are really honing in on these patterns, right?
0:15:40.500 --> 0:15:47.190
Will Lytle
What's happening in terms of change and what impact that's having, what's happening in terms of carryover work and how can we mitigate that over time?
0:15:48.420 --> 0:15:58.180
Will Lytle
How we ultimately driving towards these Sprint completion goals and then obviously looking at the volatility now, the one thing I would add here and I can't demo this cause it doesn't exist in the data.
0:15:59.180 --> 0:16:2.350
Will Lytle
Umm, but I don't know if it's something Ideagen's interested in.
0:16:2.360 --> 0:16:13.290
Will Lytle
I don't know if it's something that a couple of teams want to trial, but we have a few clients that actually track their Sprint goals and obviously you'll be well aware with Chira.
0:16:13.780 --> 0:16:21.850
Will Lytle
There's a goal section at the top, which is basically just unstructured free text, and that's not particularly helpful when you're trying to measure.
0:16:21.860 --> 0:16:27.620
Will Lytle
It's good as a UI reminder of what your goals are, but you can't measure that box because that box is just unstructured text.
0:16:28.640 --> 0:16:39.710
Will Lytle
So what they do is they create what they call an issue type called the sprinkle and they will treat that like every other ticket like a story or a bug or a a task.
0:16:39.820 --> 0:16:47.640
Will Lytle
OK, so I'll create one or two goals or maybe three goals for that Sprint, SO3 separate tickets and they will add it to that Sprint, OK.
0:16:48.520 --> 0:16:58.810
Will Lytle
And the reason I love this idea is because this view here is very much focused on the executional side of the tickets themselves, right.
0:16:59.220 --> 0:17:1.930
Will Lytle
Whereas there's a kind of a separate question.
0:17:1.940 --> 0:17:10.640
Will Lytle
Arguably, maybe even more important, which is regardless of all of this, which helps us understand how we're driving scrum, behavior and managing our sprints.
0:17:11.390 --> 0:17:13.980
Will Lytle
To what extent did we accomplish our goals right?
0:17:13.990 --> 0:17:18.790
Will Lytle
Because we could deliver all of our tickets, but if we didn't accomplish our goals, that's not great.
0:17:19.30 --> 0:17:25.220
Will Lytle
That said, we could deliver 70% of our tickets, which doesn't sound great, but we accomplished all of our goals right.
0:17:25.350 --> 0:17:34.800
Will Lytle
So I love your idea because I think it provides teams with a different point of view in terms of the the ultimate thing that you're trying to do here, which is deliver your sprinkles.
0:17:35.30 --> 0:17:39.560
Will Lytle
So if there are teams that wanted to do this in, test it and try it out, I definitely recommend it again.
0:17:39.890 --> 0:17:52.640
Will Lytle
You probably need help from an admin creating the issue type, but essentially what you can do is you could even trial it with like a task or something like that and then put a label as a Sprint goal.
0:17:52.910 --> 0:17:58.50
Will Lytle
But what you basically do is and maybe this isn't the right metric for it.
0:17:58.60 --> 0:18:0.420
Will Lytle
You could actually use something like Sprint completion rates.
0:18:0.590 --> 0:18:10.30
Will Lytle
So if we go into here and we go down to the one of the Sprint completion rates, you would just apply the filter there to focus on a task with a label of sprinkle.
0:18:10.40 --> 0:18:16.580
Will Lytle
Or if you do get an issue type created just the sprinkle and then you can actually see how we're delivering our sprinkles in combination with this.
0:18:17.690 --> 0:18:23.150
Will Lytle
And I think that's a very powerful view and a very meaningful view as well when trying to drive motivation.
0:18:24.300 --> 0:18:27.670
Will Lytle
Ideagen hasn't done this yet, but I know from working with a lot of our clients.
0:18:28.870 --> 0:18:36.680
Will Lytle
This metric here in particular has the highest correlation with engineering satisfaction right.
0:18:36.690 --> 0:18:55.320
Will Lytle
In Scrum, teams that we've seen so far, and I think that's common sense, really at the end of the day, because I think if a team is able to consistently scope out their goals and has the opportunity to deliver those goals without priorities changing or things being distracted or whatever, it's highly motivating.
0:18:55.910 --> 0:18:56.140
Speaker 1
Umm.
0:18:55.370 --> 0:19:2.840
Will Lytle
Whereas if your scope is always changing and you're always being set up to never quite accomplish what you've told you know you need to accomplish.
0:19:2.930 --> 0:19:6.40
Will Lytle
That can be quite demoralizing, especially if it's done on a sustained basis.
0:19:6.50 --> 0:19:25.450
Will Lytle
So I do think from a leadership perspective, whether you're a team lead, a scrum master, an engineering manager, you know, whatever your role is and in any form of leadership position, this is really an important metric, not only in terms of your delivery predictability, but also getting a good eye on how do I drive, you know, kind of positive and motivated environment with an engineering organization.
0:19:25.880 --> 0:19:30.800
Will Lytle
Obviously, if you're using Scrum, that's not going to be possible, but OK, I'll pause there.
0:19:29.570 --> 0:19:30.860
Speaker 1
OK. Uh.
0:19:30.810 --> 0:19:31.430
Will Lytle
Any questions?
0:19:31.440 --> 0:19:31.840
Will Lytle
Any comments?
0:19:40.420 --> 0:19:42.530
Emma Woodcock
And I'll just. Sorry, go on.
0:19:39.690 --> 0:19:43.190
Speaker 1
I mean, yeah, maybe that could go ahead.
0:19:43.240 --> 0:19:44.910
Speaker 1
Yeah. OK.
0:19:44.590 --> 0:19:48.250
Emma Woodcock
I was going to say I quite like the idea of measuring the Sprint goal.
0:19:48.990 --> 0:20:5.60
Emma Woodcock
I'm completion because I've that's one thing that I've I've keep noticing when I'm looking at these metrics, is that the percentage of of the Sprint completed doesn't really bear any relation to whether or not we hit the Sprint goal.
0:20:5.590 --> 0:20:14.170
Emma Woodcock
And and I was kind of trying to see, you know, how do we square these two sets of data and and what should we read from it?
0:20:14.180 --> 0:20:17.930
Emma Woodcock
So yeah, if if there's a way to do that, I'd be quite interested in looking at that.
0:20:20.310 --> 0:20:20.820
Will Lytle
100%.
0:20:20.810 --> 0:20:21.920
Speaker 1
Yeah, yeah.
0:20:22.70 --> 0:20:32.280
Speaker 1
View if maybe it has some visuals right on how how it will look like then OK, ask for more feedback for those who would like to try it out.
0:20:34.340 --> 0:20:36.110
Will Lytle
I can pretend because I'd like.
0:20:36.990 --> 0:20:39.0
Speaker 1
OK, OK, alright.
0:20:40.810 --> 0:20:41.80
Speaker 1
Umm.
0:20:36.120 --> 0:20:42.970
Will Lytle
I guess we don't have the data there, but if for instance you use Sprint completion, the I'll show you how another client sets this up.
0:20:43.420 --> 0:20:44.760
Will Lytle
So the Sprint completion here.
0:20:46.770 --> 0:20:52.310
Will Lytle
So this just you not too dissimilar to the other metro we're looking at, but just a more simplified view of it.
0:20:52.570 --> 0:20:59.360
Will Lytle
But basically, Emma, what you would do is let's imagine you created an issue type called the Sprint Goal, right, which is what this other customer does.
0:20:59.850 --> 0:21:9.480
Will Lytle
Essentially what you would do is you'd go into the filter and rather than looking at all tickets in our Sprint, I just want to look at only the Sprint goals and I want to see what was done or not done by the end of the Sprint.
0:21:9.490 --> 0:21:14.600
Will Lytle
So did we accomplish the goal and we marked as completed by the end of the Sprint or not?
0:21:17.280 --> 0:21:17.490
Speaker 1
OK.
0:21:18.620 --> 0:21:18.920
Matthew Frater
You know.
0:21:14.610 --> 0:21:22.740
Will Lytle
And so obviously you don't have one here showing which is the challenge, but let's pretend security was Sprint goal, right?
0:21:23.950 --> 0:21:27.520
Will Lytle
I've no idea what's gonna show up in the data here, so let's find out, right.
0:21:27.700 --> 0:21:29.750
Will Lytle
Obviously it's not a great view, but it does it.
0:21:29.760 --> 0:21:32.450
Will Lytle
It will show you here for instance.
0:21:32.460 --> 0:21:32.730
Will Lytle
OK.
0:21:32.740 --> 0:21:36.490
Will Lytle
Well, we had one goal last Sprint and 1:05 and we didn't accomplish it.
0:21:36.760 --> 0:21:36.960
Speaker 1
OK.
0:21:36.920 --> 0:21:41.990
Will Lytle
We had four goals, which is a lot too many, but whatever, it's the data, right?
0:21:42.0 --> 0:21:43.910
Will Lytle
We completed three, but we didn't accomplish one.
0:21:43.920 --> 0:21:48.290
Will Lytle
And then in Sprint 7107, we accomplished both the goals, right.
0:21:48.300 --> 0:21:51.290
Will Lytle
So on a journey finally got there.
0:21:51.380 --> 0:21:52.110
Will Lytle
That sort of thing.
0:21:55.550 --> 0:21:55.760
Speaker 1
OK.
0:21:52.540 --> 0:21:57.30
Will Lytle
And that's basically this is the view that they use right now with them.
0:21:57.40 --> 0:21:58.220
Will Lytle
It's a very binary question.
0:21:58.630 --> 0:22:1.700
Will Lytle
They either accomplished all goals or they didn't accomplish any goals.
0:22:1.710 --> 0:22:2.990
Will Lytle
Is the way that they handle it now.
0:22:3.0 --> 0:22:7.20
Will Lytle
That's obviously the decision for you to make within your teams and your product area.
0:22:7.150 --> 0:22:9.30
Will Lytle
I kind of like that because it's a very binary.
0:22:9.40 --> 0:22:11.820
Will Lytle
You either completed what you said out to accomplish or you didn't.
0:22:11.900 --> 0:22:18.470
Will Lytle
There's no partial victories in Sprint goals, which is which is harsh but fair, I think. Umm.
0:22:20.470 --> 0:22:26.380
Will Lytle
And then that gives them an overarching view that like you know, 60% of the time will accomplish our goals, which is definitely something you want to work on.
0:22:27.130 --> 0:22:29.680
Will Lytle
If that was the case, poor emergent.
0:22:29.690 --> 0:22:43.300
Will Lytle
We're looking at their security issues, but again, as I mentioned, you know, umm, I suspension of disbelief now just punches of time. It's 25 past.
0:22:43.310 --> 0:22:44.860
Will Lytle
I'll I'll move through a few of the more.
0:22:44.910 --> 0:22:49.880
Will Lytle
I tried to accommodate some of the what I wanted to look at was more the aging WIP one.
0:22:49.890 --> 0:22:53.850
Will Lytle
This is relatively newer metric, one that's been around now for a couple of months.
0:22:55.850 --> 0:23:12.510
Will Lytle
It would aging WIP does or what's in intended to do is give you a kind of a real time view throughout certain stages, certain defined stages of your SDLC where your live tickets are relative to where similar tickets have been historically on their way to being delivered.
0:23:12.830 --> 0:23:21.490
Will Lytle
OK, now a lot of clients when they first look at this metric will look at something like this because inevitably there will be hygiene work that needs to be done.
0:23:21.500 --> 0:23:28.700
Will Lytle
So there is a task that is in development and has been in development for 458 days.
0:23:28.810 --> 0:23:32.860
Will Lytle
I am guessing that that is probably not gonna be done and probably just needs to be closed off.
0:23:32.950 --> 0:23:36.860
Will Lytle
So like, I guess surprisingly to me, I wasn't expecting the.
0:23:36.900 --> 0:23:39.40
Will Lytle
There's so much hygiene to be used for this.
0:23:39.50 --> 0:23:40.580
Will Lytle
At first, that's the case.
0:23:40.590 --> 0:23:44.700
Will Lytle
Now I'm just going to filter out tasks at the moment so that we can get a more normalized view of the data.
0:23:44.790 --> 0:23:53.20
Will Lytle
So it's less kind of red and basically what you would do with this metric and what a lot of clients this is particularly critical for a Kanban team.
0:23:53.90 --> 0:23:55.950
Will Lytle
In fact, arguably the most important metric for a can ban team.
0:23:55.960 --> 0:24:3.280
Will Lytle
But I do think that scrum teams equally can get a lot of value, but also at the same time live view is doing similar things with this.
0:24:3.890 --> 0:24:15.660
Will Lytle
But essentially what this view allows you to see is you might say, OK, I only wanna focus focus on certain stages of the SDLC, so I've picked the stages that I care about.
0:24:15.700 --> 0:24:17.750
Will Lytle
I kind of your cycle time from one way.
0:24:17.760 --> 0:24:20.150
Will Lytle
Start development until we deliver to something.
0:24:20.240 --> 0:24:21.830
Will Lytle
It covers all of these statuses.
0:24:22.360 --> 0:24:23.590
Will Lytle
I want to focus.
0:24:23.640 --> 0:24:33.840
Will Lytle
I've done this mostly for hygiene and the like, making it look clean and this example is focusing only on stories and support issues, but you might want to include bugs and so on.
0:24:34.690 --> 0:24:40.890
Will Lytle
Basically what this is showing you is all of your inflight work, so we can see that we have one umm ticket here.
0:24:41.810 --> 0:24:55.990
Will Lytle
The story, which is 8 points and it's currently in development now, it has been in development now for roughly 9 days, right, which puts it into the 85th percentile, probably halfway through the 85th percentile.
0:24:56.0 --> 0:25:0.870
Will Lytle
So maybe closer somewhere to the 90th percentile compared to how we've historically worked.
0:25:1.220 --> 0:25:13.30
Will Lytle
Now, this team in particular, because they have such a high time in development, right, there's a big kind of jump between these two in development and kind of the the code review in progress stages.
0:25:13.40 --> 0:25:14.370
Will Lytle
I didn't know which one was being used.
0:25:14.380 --> 0:25:22.220
Will Lytle
Still, I mean in progress might not actually be required anymore if it's been replaced by in development, so I'm gonna remove that for a second.
0:25:23.140 --> 0:25:23.690
Will Lytle
Umm.
0:25:24.80 --> 0:25:31.110
Will Lytle
But essentially what this shows you is where the ticket is currently compared to historical tickets, at what percentile?
0:25:31.120 --> 0:25:33.690
Will Lytle
So right now it's, you know, 85th percentile.
0:25:35.350 --> 0:25:39.490
Will Lytle
We're entering in the 85th percentile, cause I've removed the in progress from the overall calculation.
0:25:39.950 --> 0:25:57.400
Will Lytle
Now, if this ticket is moved into code review, it will still remain in that, but if we're able to actually get it through into ready for test today that it will suddenly move below there and it will move into the 71st, 70th percentile, right?
0:25:57.620 --> 0:25:58.940
Will Lytle
So it shows you kind of.
0:25:59.310 --> 0:26:10.430
Will Lytle
If you were to kind of work through this and prioritize it today, it would basically move directly right across this chart and would show you ultimately where it will land relative to the historical data for that team, right.
0:26:11.0 --> 0:26:20.390
Will Lytle
Typically, you'd expect to see more of a pop, pop, pop pop up, but the reason for this team why it's kind of shaped in this way is very largely because of.
0:26:22.460 --> 0:26:24.630
Will Lytle
This metric here, which is their cycle time.
0:26:25.120 --> 0:26:36.590
Will Lytle
OK, so the team doesn't actually spend a lot of time comparatively and ready for tests and in test and awaiting merge and blocked in code review, all of these things are relatively short comparative to the cycle time.
0:26:37.960 --> 0:26:44.450
Will Lytle
But this would be, you know, you're looking at a story 14 days in development for a single story is is quite high.
0:26:46.160 --> 0:26:55.650
Will Lytle
You know, typically you would expect, especially if it's a scrum team, you would expect an average story to be far less than the amount of days and an actual Sprint.
0:26:55.660 --> 0:27:14.260
Will Lytle
But this is actually the same amount of days as an actual Sprint, so it suggests to me that either there's something going on with the hygiene or uh, you know, if I'm this team here I'm I'm thinking, OK, do we need to start breaking down our stories a bit more because if if these are representative of the size, then perhaps yes, Matthew.
0:27:16.460 --> 0:27:17.50
Matthew Frater
Yeah. Hi.
0:27:17.60 --> 0:27:17.930
Matthew Frater
Well, thank you.
0:27:18.40 --> 0:27:28.610
Matthew Frater
But the question I've got really relates to what, what, what you're thinking about it for a story fails, QA gets put back into development after being everybody thought ready to merge.
0:27:31.610 --> 0:27:32.230
Will Lytle
In terms of.
0:27:31.470 --> 0:27:32.370
Matthew Frater
Like can you account for that?
0:27:36.610 --> 0:27:36.840
Matthew Frater
Yeah.
0:27:34.280 --> 0:27:38.150
Will Lytle
So it will still show you that time overall, right?
0:27:38.270 --> 0:27:45.100
Will Lytle
I think where and this is I was actually interested in looking at this for this particular one, so there's a metric and I did this because we had a team.
0:27:45.110 --> 0:27:52.50
Will Lytle
There's actually a webinar from one of our teams that was looking at this problem and there was what was clear is the team was oversizing their issues.
0:27:54.630 --> 0:27:56.10
Will Lytle
We're not even oversizing.
0:27:56.20 --> 0:28:2.70
Will Lytle
They were accepting too many eights and fives coming into their sprints rather than challenging those and trying to break them down.
0:28:2.80 --> 0:28:23.0
Will Lytle
And as a result, there's a lot of risk being carried in, so there is a there is a metric here that kind of works in collaboration with that, which is your return rate and this allows you to specifically pick any transition between statuses that for you might represent a regression, OK and then it will show you the proportion of time that your tickets are regressing.
0:28:23.10 --> 0:28:24.220
Will Lytle
So example here.
0:28:24.230 --> 0:28:25.820
Will Lytle
I've picked all of these transitions.
0:28:26.400 --> 0:28:34.90
Will Lytle
I've focused purely on stories and tasks, and I can see that on average our return rate is 20%, which isn't particularly high.
0:28:35.40 --> 0:28:53.290
Will Lytle
Umm, I was expecting maybe to see it be a little bit higher for a team that spends, you know if if if the tickets are that high then that the other way of being able to look at that is actually something that's in the current North Star metrics which is this relationship here of stories and tasks, livered versus bugs and defects created.
0:28:53.600 --> 0:29:2.400
Will Lytle
So you want to have a much higher proportion of stories and tasks delivered than bugs created in order to kind of demonstrate that a team is effectively breaking things down?
0:29:2.410 --> 0:29:12.170
Will Lytle
That's one of the reasons why this is such an effective metric to generally looking at the high correlation between those two, the choose to break down the two, going back to your specific question, what do I think about it?
0:29:13.390 --> 0:29:20.410
Will Lytle
Obviously, anything that is regressing is, you know you, you you want to be able to apportion that time realistically.
0:29:21.680 --> 0:29:25.800
Will Lytle
So if you if if in development is so high because of a high return rate.
0:29:27.750 --> 0:29:35.960
Will Lytle
Then you should be able to see that very clearly evidenced here in the return rate or there's another one called first time pass rate, which kind of measures the opposite of this.
0:29:36.970 --> 0:29:39.480
Will Lytle
You'd also be able to see potentially in the bug resolution time.
0:29:39.490 --> 0:29:42.410
Will Lytle
How much is being done so that those are two ways of looking at it?
0:29:46.690 --> 0:29:50.130
Will Lytle
Umm, the bug resolution time.
0:29:52.690 --> 0:29:58.190
Will Lytle
At the time which PR is going to skip to this one, first, the time to merge PR's is quite an interesting one.
0:29:58.290 --> 0:30:2.840
Will Lytle
Most most teams are trying to give time to merge PR's within 24 hours.
0:30:3.750 --> 0:30:10.160
Will Lytle
OK, now there are some interesting themes I think we spoke about this some weeks ago.
0:30:10.220 --> 0:30:18.990
Will Lytle
So so this this looks essentially the more or less the code review process right from a PR being open to being reviewed, commented, and ultimately merged.
0:30:19.460 --> 0:30:40.180
Will Lytle
And I don't know if this applies to this specific team, but when you look at how these Piers break down by different repositories, right there is the potential I think for for for some teams where if they're working in a shared environment where they're dependent on other other team, naturally their PR's are going to start to take a lot longer.
0:30:40.350 --> 0:30:42.140
Will Lytle
I think we were looking at this a couple of months ago.
0:30:44.750 --> 0:30:54.260
Will Lytle
The team that was we were looking at, I think I had three or four repositories and the ones that they kind of maintain themselves that are very good Sprint time to merge PR's.
0:30:55.440 --> 0:30:57.80
Will Lytle
But there is a different one.
0:30:57.90 --> 0:31:2.650
Will Lytle
Again, I don't know if it's this or a different, but it definitely wasn't this, but I don't know if this is a shared repository or not.
0:31:2.660 --> 0:31:10.230
Will Lytle
What was quite clear is that there's a high correlation with, you know, the more the word dependent on other teams being involved in the pull request process.
0:31:10.440 --> 0:31:13.130
Will Lytle
It had a factor of eight times of slow.
0:31:13.220 --> 0:31:15.370
Will Lytle
Now, why does this matter so much?
0:31:15.700 --> 0:31:16.110
Will Lytle
Really.
0:31:16.120 --> 0:31:21.130
Will Lytle
Because the time to merge PR for most clients represents about 20 to 30% of your cycle time.
0:31:21.970 --> 0:31:26.740
Will Lytle
Now you figure the average cycle time right now for a story is about 16.6 days.
0:31:27.650 --> 0:31:36.570
Will Lytle
It takes 100 hours, so you know roughly 4 days to get through the actual Peru request process on average, right?
0:31:39.50 --> 0:31:42.580
Will Lytle
I can't tell you the reasons why this is, but for me this is.
0:31:43.590 --> 0:31:44.830
Will Lytle
This is a big flag, right?
0:31:44.840 --> 0:31:48.930
Will Lytle
This is this is something that has a developed, you know, set up like a development team.
0:31:48.940 --> 0:31:55.150
Will Lytle
I want to actually explore this and understand what's driving which drive in this data right.
0:31:57.770 --> 0:32:10.820
Will Lytle
Is it dependencies on other teams and therefore maybe we need to get to, you know, get together with the other team leads and try to figure out a way of of optimizing this process a little bit or splitting out the code base and being able to allocate responsibility little bit differently.
0:32:10.830 --> 0:32:27.800
Will Lytle
This is arguably, I think one of the big areas to consider and do to take a look at time to review is pretty solid, but it ultimately it's about time to get approval, which either means there's a lot of back and forth or ultimately got.
0:32:27.810 --> 0:32:34.340
Will Lytle
I can tell you, I mean that that an engineering team can have a very quick and sensible conversation about trying to identify what are the reasons behind these.
0:32:35.250 --> 0:32:35.990
Will Lytle
Yes, drum.
0:32:37.30 --> 0:32:37.440
Speaker 1
You want.
0:32:37.450 --> 0:32:52.910
Speaker 1
The concern is that like here is a people are maybe try to avoid some something, a pull request on a Friday because you know Saturday and Sunday will be counted and then that will spike out.
0:32:53.110 --> 0:32:54.180
Speaker 1
So what was your thought on that?
0:32:56.270 --> 0:33:0.830
Will Lytle
I think statistically speaking, you'll find that that's not the case if you look at the days.
0:33:3.610 --> 0:33:3.940
Will Lytle
So.
0:33:6.940 --> 0:33:8.140
Will Lytle
I think if people's.
0:33:11.180 --> 0:33:16.870
Will Lytle
If the takeaway here is to stop working on Fridays because it might carry over to the weekend, I think we've sort of missed the point.
0:33:18.780 --> 0:33:19.0
Will Lytle
Right.
0:33:19.570 --> 0:33:21.170
Will Lytle
Umm no.
0:33:21.230 --> 0:33:21.980
Will Lytle
If, if.
0:33:21.990 --> 0:33:24.160
Will Lytle
If that's the ultimate takeaway, I that's fine.
0:33:24.170 --> 0:33:26.80
Will Lytle
But I think I'm.
0:33:26.260 --> 0:33:27.230
Will Lytle
I don't know what to tell you.
0:33:27.240 --> 0:33:34.990
Will Lytle
There at room, I think that's a conversation you need to have with the teams, cause I think that's quite clearly the the wrong outcome to have here on these metrics, right.
0:33:36.910 --> 0:33:37.730
Will Lytle
For obvious reasons.
0:33:42.370 --> 0:33:43.510
Will Lytle
Some PR count.
0:33:44.70 --> 0:33:53.130
Will Lytle
This is not a view that I don't think a lot of people have looked at yet, and I wanted to show you guys this Peter the yeah, one move on.
0:33:51.600 --> 0:33:57.490
Peter Swanborough
Umm is it not possible to simply omit non working days from the data?
0:33:59.820 --> 0:34:10.650
Will Lytle
I'm not particularly because the concept of working day, even in an idea Gen, means a lot of different things and we have no idea where the person is based on, so we don't remove that overall.
0:34:11.40 --> 0:34:22.900
Will Lytle
Plus, our argument is is time is actual time, whether it's working days or not, because the majority of time that you don't spend working actually happens in the evenings over the course of the week, not on the weekends, right?
0:34:22.910 --> 0:34:25.780
Will Lytle
So you'd actually, if you wanted to see purely by working hours.
0:34:26.110 --> 0:34:30.260
Will Lytle
Unfortunately, we'd have to know exactly who sits where, what their current working hours are.
0:34:31.40 --> 0:34:31.580
Will Lytle
Umm.
0:34:31.720 --> 0:34:35.730
Will Lytle
And that's not something we can easily do kind of globally across all of the different teams.
0:34:35.740 --> 0:34:38.280
Will Lytle
And you know, we have people based in Asia.
0:34:38.290 --> 0:34:39.580
Will Lytle
You have people based in Europe.
0:34:39.590 --> 0:34:43.760
Will Lytle
You have people based, I think, even in the US so we show the data as it is.
0:34:44.570 --> 0:34:44.980
Peter Swanborough
OK.
0:34:45.740 --> 0:34:46.110
Peter Swanborough
Thank you.
0:34:47.80 --> 0:34:56.590
Will Lytle
Or it's umm, now the breakdowns up PR count I think is where you can have some quite interesting conversations here.
0:35:0.170 --> 0:35:3.960
Will Lytle
Point to this just looks at the the number of PR's right?
0:35:3.970 --> 0:35:6.740
Will Lytle
And I'm going to just look at productive PR's at the moment.
0:35:6.750 --> 0:35:8.460
Will Lytle
I appear ours at alternately merged.
0:35:9.410 --> 0:35:25.40
Will Lytle
OK, now the reason I like this metric and again this is sumes that it's being interpreted the right way because it's very easy to interpret this in a very naive way, which is to look at PR count by author as some form of productivity.
0:35:25.630 --> 0:35:39.40
Will Lytle
I think it in part in forms it, but you need to have a more sophisticated understanding of how developers are intended to spend their time between writing code, designing, supporting others and so on and so forth.
0:35:39.250 --> 0:35:44.830
Will Lytle
But I do think that this gives you a meaningful portion of the view on that basis.
0:35:44.840 --> 0:35:47.10
Will Lytle
So you can take a look at the PR count by author.
0:35:47.860 --> 0:35:54.750
Will Lytle
You can break that down here and actually see the size of the PR's, so there are a number of clients that use this on a regular basis.
0:35:54.760 --> 0:36:1.30
Will Lytle
To see all we actually make, are we creating PR's that are too large and that's bringing in additional risk?
0:36:1.40 --> 0:36:4.0
Will Lytle
Are there certain individuals that are doing that now?
0:36:4.10 --> 0:36:5.580
Will Lytle
I can't say that I've been doing this.
0:36:5.690 --> 0:36:6.570
Will Lytle
You know, I would doubt that.
0:36:6.580 --> 0:36:9.420
Will Lytle
I've been literally wrote 12,000 lines of code.
0:36:9.490 --> 0:36:12.100
Will Lytle
If you did bless him, that's incredible.
0:36:12.200 --> 0:36:18.20
Will Lytle
It's probably more of a library change here, but that library change even still in, you know, provides some level of risk.
0:36:18.30 --> 0:36:29.400
Will Lytle
So from this perspective you can look at it from a throughput perspective, but also by the sizing perspective of it where I think this data is particularly interesting is if I look at it, this data broken down by participant.
0:36:29.690 --> 0:36:42.800
Will Lytle
So overall, we had 75 PR that have been merged over the course of the last 12 weeks for this particular team, we can see how many of those PR's have been, uh, you know, done by author.
0:36:42.810 --> 0:36:45.450
Will Lytle
So how does that 75 breakdown across the different authors?
0:36:46.510 --> 0:36:50.60
Will Lytle
Participant shows you something very different, right?
0:36:50.70 --> 0:37:1.190
Will Lytle
So there's Hafiz here, so one might look at this chart and think OK Hafiz is not a particularly productive member of this team, right?
0:37:1.660 --> 0:37:4.670
Will Lytle
Which is exactly why I'm always very cautious about these metrics.
0:37:5.100 --> 0:37:18.720
Will Lytle
The reality, if I look at this data by participant, I see something very different, which is I see that Avis is actually one of the most essential Members of this team because they are of the 75 PR's that have been merged.
0:37:18.950 --> 0:37:21.320
Will Lytle
He has participated in 43 of them.
0:37:21.970 --> 0:37:23.580
Will Lytle
I he has commented on them.
0:37:23.590 --> 0:37:24.560
Will Lytle
He has reviewed them.
0:37:24.570 --> 0:37:25.420
Will Lytle
He has merged them.
0:37:25.430 --> 0:37:28.980
Will Lytle
He has approved them, so the role that he is playing is slightly different.
0:37:28.990 --> 0:37:42.300
Will Lytle
So if you are an engineering lead, right, this is something a lot of our clients look at because it starts to then bring a more sophisticated view of the roles of different people are playing in the team and whether, for instance, you might think that you know Hafiz, this is great that you're doing this.
0:37:42.310 --> 0:37:46.490
Will Lytle
But actually I need you to kind of I think we've we've overcorrected in this direction, right.
0:37:46.500 --> 0:37:49.720
Will Lytle
I wanna, you know, maybe we should look at finding a little bit more balance next month, right?
0:37:49.730 --> 0:37:52.290
Will Lytle
Because I do need you to actually work on XY and Z.
0:37:53.850 --> 0:38:2.360
Will Lytle
On the flip side, you can see that certain people might just be authoring but not participating, right, and so there might be a conversation there around I.
0:38:3.90 --> 0:38:13.750
Will Lytle
It's great that you're so productive from, you know, from a PR perspective, but I need you to work a little bit more on supporting different people on the team because the more we depend on one person, then the longer these things are gonna take.
0:38:13.760 --> 0:38:17.760
Will Lytle
And this kind of goes hand in hand with the collaboration metric.
0:38:18.70 --> 0:38:22.710
Will Lytle
Now, I would say generally with this diagram here, it's incredibly healthy, right?
0:38:23.850 --> 0:38:29.840
Will Lytle
For those that that haven't used this metric before, it's not a metric in the sense of of a number.
0:38:29.950 --> 0:38:34.340
Will Lytle
But what this shows you is the individual interactions in the pull request process.
0:38:34.510 --> 0:38:45.380
Will Lytle
So who is working with whom and what proportion of time are people supporting others so you can see the outside of it will show you the proportion of things, proportion of participants who they're actually participating with.
0:38:45.570 --> 0:38:47.800
Will Lytle
So you can see patterns of participation.
0:38:48.50 --> 0:38:53.120
Will Lytle
For instance, certain people only working with other people, but you can see broadly what you're aiming for.
0:38:53.130 --> 0:38:56.970
Will Lytle
Here is a fairly well balanced and distributed distribution across these.
0:38:57.280 --> 0:39:2.390
Will Lytle
Now we're looking at a whole bunch of repositories, so this is more around People collaboration.
0:39:2.400 --> 0:39:4.540
Will Lytle
But if you wanted to look at selenium for instance.
0:39:6.780 --> 0:39:18.350
Will Lytle
And this might not be a good example of it, but selenium shows us something maybe slightly different, which is when we're working in this area of the code base, actually we're very reliant on Siri.
0:39:18.700 --> 0:39:26.310
Will Lytle
Now again, this is sliding into this could be this could be something totally different, but imagine it is a just a normal repository, right?
0:39:26.410 --> 0:39:47.960
Will Lytle
This could suggest that either there's a potential single point of failure and knowledge, or that one person is picking on taking on too much of the responsibility and the team would actually become far more efficient if that responsibility for reviewing PR's was distributed, which is to be part process change, part confidence building, but also part knowledge distribution.
0:39:48.500 --> 0:39:57.10
Will Lytle
So a lot of our clients use this very heavily for identifying areas of their code base where there appears to be knowledge centralized in one person.
0:39:57.370 --> 0:40:1.760
Will Lytle
That's a risk, obviously from a knowledge perspective, but also not going to do anything to speed the team up.
0:40:2.710 --> 0:40:7.220
Will Lytle
Also, they look at it a lot for new joiners, so I can see for instance.
0:40:8.220 --> 0:40:10.910
Will Lytle
But let's say it's Sateesh has just joined the team.
0:40:10.960 --> 0:40:13.870
Will Lytle
I can see that you know in the last on Thor.
0:40:13.930 --> 0:40:19.460
Will Lytle
No, he's just started getting involved, but actually it's part of his development program and on boarding process.
0:40:19.470 --> 0:40:23.970
Will Lytle
And I want him to be working to review and approve more of the PR's.
0:40:24.350 --> 0:40:25.390
Will Lytle
Right. So.
0:40:27.420 --> 0:40:45.870
Will Lytle
Those 3 metrics, I think in combination or three views, the PR count by approver by participation and by PR collaboration really give a team lead some very interesting things to think about and potentially talk about as part of their risk mitigation with knowledge, knowledge distribution as well as onboarding new folks on our team.
0:40:51.140 --> 0:40:51.570
Will Lytle
Umm.
0:40:52.760 --> 0:40:58.890
Will Lytle
Last but not least is is the bug resolution time and I won't spend a lot of time on this because it is what it is right?
0:40:58.900 --> 0:41:2.520
Will Lytle
How long does it take for us from a bug being open to being resolved, but?
0:41:5.160 --> 0:41:6.460
Will Lytle
Why does this matter?
0:41:6.930 --> 0:41:8.920
Will Lytle
I'm and and why do people care about it?
0:41:8.930 --> 0:41:15.20
Will Lytle
So much so there's the obvious answer to this, which is if there's a bug, it probably impacts our users, and that's not good.
0:41:15.130 --> 0:41:19.800
Will Lytle
And so the longer that thing exists, the more our user impacted and that's not good, right?
0:41:19.850 --> 0:41:27.400
Will Lytle
That's the obvious answer, but where high performing to a lot of our clients are looking at this is is from a slightly different perspective.
0:41:27.410 --> 0:41:33.950
Will Lytle
So this metric obviously only looks at the looks at all the bugs that you have completed, right?
0:41:33.960 --> 0:41:37.630
Will Lytle
So they were important enough to complete the question.
0:41:37.640 --> 0:41:45.380
Will Lytle
Here is 1 on resource utilization and how effectively we're spending our time to to resolve bugs.
0:41:45.930 --> 0:41:47.960
Will Lytle
If I am an engineer, right?
0:41:48.320 --> 0:41:53.820
Will Lytle
And I've just written a new feature and that feature has gone into QA.
0:41:54.830 --> 0:42:4.400
Will Lytle
If I get a bug back the next day, it's going to typically be relatively trivial for me to fix that bug, assuming it's not something fundamentally wrong in the logic, right?
0:42:5.190 --> 0:42:16.510
Will Lytle
However, if that bug sits in a backlog for 55 days on average, right, and obviously there's this one here, couple here that are skewing this a bit.
0:42:17.320 --> 0:42:21.520
Will Lytle
So I'm going to just for the sake of mass, move this even to 85%.
0:42:25.560 --> 0:42:25.860
Will Lytle
OK.
0:42:25.870 --> 0:42:27.410
Will Lytle
Brings it down a little bit.
0:42:27.420 --> 0:42:28.0
Will Lytle
Still not enough?
0:42:28.10 --> 0:42:29.170
Will Lytle
There's still a few more up there.
0:42:29.340 --> 0:42:32.180
Will Lytle
I think there was a bulk closure here where they were closed as resolved.
0:42:32.190 --> 0:42:32.870
Will Lytle
There's something but.
0:42:34.880 --> 0:42:36.430
Will Lytle
Yeah, yeah, alright.
0:42:38.930 --> 0:42:40.280
Will Lytle
We'll get there eventually.
0:42:41.690 --> 0:42:42.290
Will Lytle
Maybe we won't.
0:42:46.200 --> 0:42:58.290
Will Lytle
Would recommend that if you do do bulk closures, please make sure you mark them as resolution not done so that you have a way of actually excluding them from the data because those were just closed as done.
0:42:58.620 --> 0:43:0.20
Will Lytle
But I'm guessing they weren't all done.
0:43:0.30 --> 0:43:6.420
Will Lytle
I'm guessing that was just built closure of hygiene, but let's say that this was more realistic, right?
0:43:6.430 --> 0:43:8.620
Will Lytle
And this is a lot more healthy, right?
0:43:8.630 --> 0:43:15.670
Will Lytle
Because what this is then saying is that an average, you know, our tickets are going to developers and then they can resolve within 9.3 days.
0:43:15.990 --> 0:43:28.190
Will Lytle
The difference here being is that the longer it takes for you to resolve bugs right, the longer the time is between the work we are doing in the code base that originally created this bug versus when this bug came back to us.
0:43:29.80 --> 0:43:37.70
Will Lytle
And it is significantly faster for developer to have work on short feedback loops and resolve these quickly, which is going to have a direct impact on the productivity of a team.
0:43:37.500 --> 0:43:51.270
Will Lytle
Now this is part responsibility of the team, but really part responsibility of the product owner as well, because if the product owner is just prioritizing stories at the consequence of bugs and that bug backlog is building up over time, they are forcing this problem.
0:43:52.300 --> 0:43:56.570
Will Lytle
Obviously unknowing me, you know, nobody nobody knowingly makes this problem in thing.
0:43:56.580 --> 0:43:59.590
Will Lytle
But the reality is, is we are all working to Rd maps.
0:43:59.600 --> 0:44:17.290
Will Lytle
Plandek is working to Rd maps and so we are making conscious decisions on our side to make sure that we are very, very keen on keeping this number as low as possible because we know that it takes they say something like for after two weeks it takes the develop after three days it takes the developer 8 times as long.
0:44:17.300 --> 0:44:19.470
Will Lytle
I'm not sure I totally buy that or how that was measured.
0:44:19.720 --> 0:44:23.630
Will Lytle
Point being here is it does take a developer a hell of a lot longer to go back.
0:44:23.640 --> 0:44:24.930
Will Lytle
Remember what they're working on?
0:44:24.940 --> 0:44:27.390
Will Lytle
Look through the code base and trying to figure out what is that thing.
0:44:28.500 --> 0:44:36.420
Will Lytle
Whereas if the bug was reported to them a day later, they'd be much easier to be able to be much easier for them to be able to OHS this, resolve it and move on in life.
0:44:36.600 --> 0:44:38.470
Will Lytle
And that has a huge impact on capacity.
0:44:38.760 --> 0:44:43.280
Will Lytle
What the team has the ability to get through and a particular Sprint, so I would definitely take that in mind.
0:44:44.40 --> 0:44:49.320
Will Lytle
Umm, now on the Kanban side, I'm I'm conscious there are some can ban teams here.
0:44:50.210 --> 0:44:53.200
Will Lytle
I won't spend a lot of time didactically going through campaign.
0:44:54.790 --> 0:45:2.40
Will Lytle
There is an article which we've pointed to a large number of times that we've written E that corresponds to this dashboard.
0:45:2.50 --> 0:45:2.740
Will Lytle
If you spell it correctly.
0:45:5.190 --> 0:45:5.890
Will Lytle
Umm.
0:45:7.170 --> 0:45:8.970
Will Lytle
Which is Key Cam then METRICS.
0:45:8.980 --> 0:45:12.420
Will Lytle
I'm Plandek and this is a refresher on, you know, Cam band.
0:45:12.430 --> 0:45:13.280
Will Lytle
What is Cam band?
0:45:13.290 --> 0:45:18.980
Will Lytle
What are the behaviors you're trying to optimize for more of the kind of background context and introduce introduce to some of the metrics.
0:45:19.630 --> 0:45:27.120
Will Lytle
This article works hand in hand with this, but ultimately the end of the day if you're doing Kanban, you shouldn't be doing Kanban because you're trying to avoid doing sprints.
0:45:27.590 --> 0:45:28.860
Will Lytle
But that's not the right reason.
0:45:28.930 --> 0:45:39.120
Will Lytle
I know that's a common reason, but it's not the right reason I'm if you're trying to do Cam ban, it's because you're effectively trying to drive a system where you're balancing input and output, right?
0:45:39.370 --> 0:45:46.650
Will Lytle
And you're able to balance that system through effectively identifying alleviating waste in that process and you're able to.
0:45:48.720 --> 0:45:54.110
Will Lytle
Work on tickets work on a backlog of similarly sized items, right?
0:45:54.120 --> 0:45:58.650
Will Lytle
So the can man team needs this similar size that items in order to be able to drive and measure the right behaviors.
0:45:59.710 --> 0:46:17.40
Will Lytle
So lead time to value we've we've spoken about a little bit cycle time from Dev start to done time to merge PR S We've talked about already, throughput is your main measure here of throughput from the system and what you need to be able to do is balance throughput with input into that system.
0:46:17.150 --> 0:46:26.300
Will Lytle
So you can see here is this system is relatively well balanced, 56 in 150 out in terms of what's created versus what's completed into the system.
0:46:26.310 --> 0:46:27.100
Will Lytle
Into the system.
0:46:27.490 --> 0:46:41.160
Will Lytle
Now there is an argument here that there is a strong backlog right, and the only way that this team is currently going to be able to burn down that backlog with the system input and output as is, is by increasing the output or slowing the input to be honest.
0:46:41.170 --> 0:46:42.500
Will Lytle
But you're not going to.
0:46:42.510 --> 0:46:43.630
Will Lytle
You're not going to slow input.
0:46:43.690 --> 0:46:44.480
Will Lytle
Let's be honest.
0:46:44.570 --> 0:46:52.260
Will Lytle
So you can either do that through elevating ways in the process, or by upscaling or upsizing the capacity of the team.
0:46:52.750 --> 0:47:0.970
Will Lytle
OK, so the flow efficiency which will partially work will help you to measure the proportion of time that tickets are actively being worked on.
0:47:0.980 --> 0:47:5.510
Will Lytle
And this is an essential one for Kanban teams, but also I think very useful for Scrum teams.
0:47:6.230 --> 0:47:8.170
Will Lytle
But maybe in a slightly different part of that process.
0:47:8.180 --> 0:47:19.830
Will Lytle
But basically what this shows you of all the tickets that we have delivered over the last 12 weeks, if we define these databases as the statuses where somebody was actively working on the ticket, essentially how much time was that ticket queuing?
0:47:19.920 --> 0:47:29.260
Will Lytle
What proportion of time was that taking, queuing and so the time it was active over the over the total time is essentially your workflow efficiency, otherwise known as your flow efficiency.
0:47:29.310 --> 0:47:41.100
Will Lytle
So one of your key flow metrics now this would be somewhat depending on the workflow, but you can see exactly why this can't be so useful for a team to be able to identify waste in their process.
0:47:41.410 --> 0:47:42.600
Will Lytle
So this will color code.
0:47:42.610 --> 0:47:52.520
Will Lytle
The active is orange and inactive or queuing is blue and you can see exactly where the largest amount of queuing time is picked up by this particular team.
0:47:53.530 --> 0:47:53.790
Will Lytle
What was?
0:47:53.800 --> 0:47:56.90
Will Lytle
You could potentially argue, but it could be closed.
0:47:56.100 --> 0:47:57.780
Will Lytle
But removed from this metric.
0:47:58.80 --> 0:48:4.700
Will Lytle
But this allows you then to like visualize that active in queuing, similar to actually how the workflow is set up itself.
0:48:4.790 --> 0:48:22.90
Will Lytle
So if you wanted to improve the work efficient deploy efficiency of this team, right, the backlog is kind of critical area, either the ultimate backlog or the ready for development backlog are the kind of two areas that are critical awaiting refinement as well that.
0:48:24.480 --> 0:48:24.910
Will Lytle
Umm.
0:48:26.430 --> 0:48:30.540
Will Lytle
8 minutes left before I, before I go into anything else.
0:48:30.550 --> 0:48:33.610
Will Lytle
I guess I wanted to pause and.
0:48:36.980 --> 0:48:41.300
Will Lytle
Happened to use the next 9 minutes going over any specific questions or specific use cases.
0:48:42.580 --> 0:48:44.600
Will Lytle
I'm there.
0:48:44.610 --> 0:48:55.700
Will Lytle
There are a load of different use cases and so it's hard for me sometimes to be able to just randomly generate potential use cases, but hopefully some of these been helpful today, but if there's any real ones I think that would be yes, yes ma'am.
0:48:57.140 --> 0:48:58.450
Mah Jin-Khai
Just one question though.
0:48:58.460 --> 0:48:59.450
Mah Jin-Khai
What is the?
0:48:59.820 --> 0:49:3.280
Mah Jin-Khai
What is the expectation and definition of the high performance teams?
0:49:4.140 --> 0:49:9.480
Mah Jin-Khai
Is there a meeting all the target of the metrics or they they something else we need to we need to know?
0:49:12.900 --> 0:49:16.130
Will Lytle
I'm getting my definition and then whether you buy it or not is up to you.
0:49:17.520 --> 0:49:19.90
Will Lytle
Umm, we don't.
0:49:19.320 --> 0:49:30.190
Will Lytle
We don't have anything in our tool that declares you or high performing or not, and the reason being is because there's a lot of context behind teams that we will never understand because of the data that we're looking at.
0:49:30.230 --> 0:49:33.700
Will Lytle
So I don't know, for instance, that you're working on a desktop application.
0:49:33.710 --> 0:49:45.910
Will Lytle
That's reasonably gonna be deployed once a quarter or maybe even once a year versus you're working on cloud native apps in AWS and you can see how both of those contexts would significantly change the type of data that we would see.
0:49:45.920 --> 0:49:50.450
Will Lytle
So Plandek does not prescribe any sort of performance bases.
0:49:50.820 --> 0:49:53.720
Will Lytle
I think my argument and the argument that I've made.
0:49:55.590 --> 0:49:58.500
Will Lytle
Uh relation to the benchmarks.
0:49:58.590 --> 0:50:13.200
Will Lytle
Otherwise high performance is a state of mind, which sounds like a cheesy thing to say, but the reality is is when you look at high performing teams, it's not that they are hitting metrics data points all the time, right?
0:50:13.620 --> 0:50:23.660
Will Lytle
It's that they are aware of what these data points are and have the ability to react and remediate when they're starting to get off track on what their plans are.
0:50:23.730 --> 0:50:26.900
Will Lytle
So high performance for me is as a team.
0:50:26.910 --> 0:50:33.760
Will Lytle
I wanna be regular, you know, high performing team is one that is regularly engaged at the data, knows exactly what's dragging them down right.
0:50:33.770 --> 0:50:44.110
Will Lytle
We can give you indicators, for instance, if this is a cloud native app, but I can tell you that you know the top 25% of Plandek clients are at the moment 17 hours.
0:50:44.160 --> 0:50:46.200
Will Lytle
I think it's the number, right?
0:50:46.450 --> 0:50:54.10
Will Lytle
So they will merge PR S within 17 hours and the top 50% I think is I have to look at the recent benchmarks that we're we've just done.
0:50:54.420 --> 0:51:5.270
Will Lytle
I can tell you where that is, but what I can't tell you as to what extent some of these teams are working in certain ways that might slow them down fundamentally or as opposed to to other ways.
0:51:5.340 --> 0:51:7.270
Will Lytle
So that's why we don't productize it as such.
0:51:7.280 --> 0:51:16.920
Will Lytle
Because we don't have context and it's not fair because I think the minute you declare a team is low performing without having 100% confidence behind that tag.
0:51:17.860 --> 0:51:22.630
Will Lytle
That tag then gets picked up by somebody else, and then other things happened which have nothing to do with the intended.
0:51:23.730 --> 0:51:26.310
Will Lytle
Umm of this right?
0:51:26.580 --> 0:51:31.10
Will Lytle
That's my view on it and it's a bit cheesy, but this is a perfect example of why that is the case.
0:51:32.90 --> 0:51:39.670
Will Lytle
When you look at Hafiz, for instance, the difference between these two charts here demonstrates exactly what I mean by the context and why that's so important.
0:51:40.920 --> 0:51:51.100
Will Lytle
So high performance is really something that you need to be driving at the team level, you know, and today is hopefully is a step in that direction of you know, this is how it working.
0:51:51.210 --> 0:51:53.240
Will Lytle
This is the behaviors we're trying to drive.
0:51:53.250 --> 0:51:59.20
Will Lytle
These are the metrics that help us measure where we are in that journey and when we get off course, we know we're off course.
0:51:59.30 --> 0:52:1.880
Will Lytle
We have a conversation about being what's driving us being off course.
0:52:1.890 --> 0:52:14.950
Will Lytle
We put some remedial actions and we get better because none of the high performing teams that teams that I would consider high performing, none of them do this well all the time like nobody does it well all the time.
0:52:14.960 --> 0:52:16.540
Will Lytle
That's not a thing, right?
0:52:16.600 --> 0:52:27.670
Will Lytle
It it's you know you will optimize for one behavior and you will inadvertently overcorrect and cause another problem and then you have to refocus on that and it's that's the thing about continuous improvement it's it's it's a never ending journey.
0:52:28.670 --> 0:52:32.390
Will Lytle
So high performance is about being on that journey in a more sophisticated way as opposed to.
0:52:33.960 --> 0:52:37.340
Will Lytle
Falling into particular benchmark or framework would be my argument.
0:52:43.310 --> 0:52:43.710
Will Lytle
Umm.
0:52:49.200 --> 0:52:51.490
Will Lytle
I think if you're not using live view, I was.
0:52:51.500 --> 0:52:56.40
Will Lytle
I was with a client yesterday doing a A the meaning we were we're looking through.
0:52:56.50 --> 0:53:4.290
Will Lytle
So it's there is a high correlation generally with performance and and interactions with live view, right, which is good to hear, it's good product feedback.
0:53:5.420 --> 0:53:13.100
Will Lytle
I think with the last five minutes I'll spend talking a little bit about live view because I think if anything, this is probably the most important thing that you should be interacting with on a daily basis.
0:53:14.350 --> 0:53:16.520
Will Lytle
Now live view what is live view.
0:53:16.530 --> 0:53:29.230
Will Lytle
So everything we've looked at today is very much historically focused, right, looking at the past, learning some lessons and taking that forward right live view is about helping you monitor what's in flight right now, either through a Sprint or through an epic.
0:53:29.950 --> 0:53:41.20
Will Lytle
And what it's doing is it's looking at your data and it's comparing it to how you have historically worked I and what it's trying to do is establish where there might potentially be some risks and how you're delivering.
0:53:41.150 --> 0:53:42.870
Will Lytle
So if we look at this particular team here.
0:53:44.170 --> 0:53:51.280
Will Lytle
Umm, you can see whether on the basis of story points or tickets, how they're distributed throughout the different status categories.
0:53:51.650 --> 0:53:57.180
Will Lytle
You can update these and the reason I say that's important is because you can see here that there are tickets without a commit.
0:53:58.350 --> 0:54:3.610
Will Lytle
What's in progress is based on what you what's configured as an in progress status in JIRA by default.
0:54:4.650 --> 0:54:8.960
Will Lytle
So that means it will pick up things like Indesign if Indesign is a blue status.
0:54:9.510 --> 0:54:11.570
Will Lytle
That said, you can just move it.
0:54:13.470 --> 0:54:14.120
Will Lytle
And apply it.
0:54:17.180 --> 0:54:17.590
Will Lytle
Right.
0:54:18.40 --> 0:54:22.390
Will Lytle
Which then, if that was in one of those statuses, would actually move that over.
0:54:22.840 --> 0:54:29.630
Will Lytle
But you can see here that one of its awaiting merge and one of its in test now interesting that they're waiting.
0:54:29.640 --> 0:54:40.960
Will Lytle
Merge doesn't have a commit that would suggest to me that that commit about PR does not link to this ticket, which is why Plandek thinks that this ticket doesn't link to any code base.
0:54:41.20 --> 0:54:47.630
Will Lytle
So that's a nice little hygiene flight for you, but the whole point with this for a team is really twofold.
0:54:48.180 --> 0:54:50.550
Will Lytle
One is how?
0:54:50.560 --> 0:54:50.890
Will Lytle
How?
0:54:50.900 --> 0:54:55.930
Will Lytle
How how can we help you broaden understanding of risk when it comes to sprints?
0:54:56.60 --> 0:55:5.0
Will Lytle
So what are the things that can happen that can potentially distract us or keep us from being a successful and accomplishing our goals right?
0:55:5.920 --> 0:55:15.550
Will Lytle
There are five examples or 10 examples here of things that we think well, we know how statistically relevant in terms of a team success rate.
0:55:15.560 --> 0:55:19.190
Will Lytle
So that left hand side will give you the overall quotient, which we can look at in a second.
0:55:19.420 --> 0:55:23.450
Will Lytle
There's one day left, right, based on the current burn down.
0:55:23.520 --> 0:55:25.100
Will Lytle
The team is on track, right?
0:55:25.500 --> 0:55:29.810
Will Lytle
So, given where they are right now, they are on track to actually meet that goal.
0:55:29.900 --> 0:55:32.90
Will Lytle
So if you do love a burn down, there you go.
0:55:32.340 --> 0:55:51.20
Will Lytle
I think what's more interesting I think is like delayed pull requests and delayed PR's because this can show you specifically we'll look at waiting merge that this support issue has been awaiting merge for 9 days, which is above the normal threshold of one day compared to support issues of five story points in this workspace.
0:55:51.30 --> 0:55:54.880
Will Lytle
So Plandek is looking at historically and it's looking at.
0:55:57.320 --> 0:56:6.130
Will Lytle
Not only comparing support issues versus other support issues, but if they're story pointed, we'll also compare 5 pointers against other five pointers, which is where we come uh this one day.
0:56:6.280 --> 0:56:8.520
Will Lytle
So it's all relative, right?
0:56:8.720 --> 0:56:13.480
Will Lytle
You could acknowledge it when you've seen it, so if not linked to any development work, you could acknowledge it would hide it.
0:56:14.130 --> 0:56:24.180
Will Lytle
Umm, you normally would be able to see the full trail, the audit trail as that moves through the different tools which you won't hear because it's not linked.
0:56:24.190 --> 0:56:27.560
Will Lytle
Any development work which suggests that basically it's it's not linked.
0:56:28.50 --> 0:56:33.950
Will Lytle
There's no link in the PR that commit to this ticket, but the idea here, and I won't go through all of these today.
0:56:34.880 --> 0:56:36.740
Will Lytle
You can click the how does it work?
0:56:36.820 --> 0:56:40.610
Will Lytle
This will give you kind of a high level understanding of the risk rating and so on.
0:56:41.100 --> 0:56:45.870
Will Lytle
But if you click here in the bottom, there's a detailed explanation behind everything in my view.
0:56:45.980 --> 0:56:48.50
Will Lytle
So you can see how the calculations are done.
0:56:48.480 --> 0:56:58.630
Will Lytle
You can see how the different insights are weighted in terms of impact to those she different wedding groups, whether they're available for epics and for sprints.
0:57:0.530 --> 0:57:12.550
Will Lytle
We'll show you the logic behind this Sprint burn down, which takes into consideration weekend days and gives you a great period of the start before establishing what the baseline is for where you should be, and it will tell you about all of the different insights.
0:57:12.560 --> 0:57:19.790
Will Lytle
Here the idea behind it really is 1 to help teams think about risk more broadly when it comes to a Sprint, and also to then give them some insights.
0:57:20.490 --> 0:57:27.390
Will Lytle
And our team, I know we're done now, so I'll, I'll leave it here, but what I'd recommend for for teams is to to use it.
0:57:27.430 --> 0:57:29.30
Will Lytle
You know, there's one day left in the Sprint.
0:57:29.550 --> 0:57:33.710
Will Lytle
So, you know, show me only the tickets that have insights against them.
0:57:33.980 --> 0:57:38.640
Will Lytle
And I wanna all open at the moment not only three here.
0:57:38.650 --> 0:57:47.220
Will Lytle
So you probably just go through them, but and maybe the start of the Sprint where there's more of these, you can actually use this to go one by one through your stand up, right.
0:57:47.450 --> 0:58:2.290
Will Lytle
And you can each have a conversation about what's driving these and have their acknowledged the insights that they're move on or actually you do something about it in that session which will help you to then umm hopefully make a big difference in how you everything.
0:58:2.300 --> 0:58:6.50
Will Lytle
So a pause because it is it is the hour.
0:58:8.640 --> 0:58:9.530
Will Lytle
Was that helpful?
0:58:9.620 --> 0:58:10.280
Will Lytle
Was that kind of what?
0:58:11.90 --> 0:58:12.100
Will Lytle
What you're looking for today?
0:58:14.370 --> 0:58:17.620
Speaker 1
Yeah, 2 there's a question and a comment.
0:58:18.130 --> 0:58:19.500
Speaker 1
So SueAnn ends.
0:58:19.640 --> 0:58:29.930
Speaker 1
Asked if there's a way to undo what is committed to the start of the spring, we have the scenario where someone was cleaning a ticket and he accidentally got allocated to a Sprint.
0:58:31.750 --> 0:58:32.960
Will Lytle
Uh, unfortunately, no.
0:58:34.290 --> 0:58:37.200
Will Lytle
Because we we we can't understand the context of accident.
0:58:37.910 --> 0:58:39.530
Will Lytle
Umm so.
0:58:42.480 --> 0:58:42.800
Will Lytle
You.
0:58:42.570 --> 0:58:47.460
SueAnn See
So the context here is that someone was cloning the ticket, so it really happened.
0:58:50.540 --> 0:58:50.640
SueAnn See
Yeah.
0:58:49.80 --> 0:58:52.190
Will Lytle
No, no, for sure, but we can't differentiate.
0:58:52.200 --> 0:58:52.410
Will Lytle
What?
0:58:52.420 --> 0:58:52.630
Will Lytle
What?
0:58:52.640 --> 0:58:52.890
Will Lytle
What?
0:58:52.900 --> 0:58:56.740
Will Lytle
What was the result of a cloning and an accident going into a Sprint versus not?
0:58:58.700 --> 0:59:2.650
Will Lytle
You could delete the clone ticket and start again, right?
0:59:3.170 --> 0:59:4.860
Will Lytle
I'm that will work.
0:59:5.810 --> 0:59:6.290
Will Lytle
Umm.
0:59:6.70 --> 0:59:6.870
SueAnn See
Umm.
0:59:7.20 --> 0:59:8.780
SueAnn See
It umm.
0:59:6.430 --> 0:59:12.540
Will Lytle
But once the ticket enters a Sprint, you essentially have committed the ticket to the Sprint, even if it's by accident.
0:59:12.550 --> 0:59:15.100
Will Lytle
We don't know that it was by accident, which is why we then show it.
0:59:19.310 --> 0:59:21.120
SueAnn See
OK, but this will mess up the metrics.
0:59:21.130 --> 0:59:27.550
SueAnn See
I mean, even if there is a a, maybe something available to the admin that will help I guess.
0:59:35.980 --> 0:59:36.160
Will Lytle
OK.
0:59:35.620 --> 0:59:42.990
Speaker 1
Well, I think, yeah, if it's accidentally created you can approach me so then or anyone else.
0:59:43.740 --> 0:59:47.590
Speaker 1
Yeah, we had a few occasions where it was mistakenly created.
0:59:54.910 --> 0:59:55.250
Speaker 1
Umm.
0:59:50.350 --> 0:59:58.620
SueAnn See
No, in this case you have to unassign from the Sprint commit, so I don't think there is a way to do that in JIRA.
0:59:58.690 --> 0:59:59.280
SueAnn See
I I'm not sure.
1:0:2.530 --> 1:0:3.180
Will Lytle
Yeah, I mean you can.
1:0:4.360 --> 1:0:4.540
Speaker 1
Yeah.
1:0:5.830 --> 1:0:6.930
Speaker 1
Umm Yep.
1:0:3.190 --> 1:0:9.70
Will Lytle
You can either delete the ticket that was accidentally created in the Sprint and start again so that it's not created in the Sprint.
1:0:9.860 --> 1:0:12.420
Will Lytle
Umm, because Jerry will have the same problem right?
1:0:12.430 --> 1:0:14.870
Will Lytle
There is gonna show you the same thing, which is that you added a ticket to the Sprint.
1:0:15.900 --> 1:0:16.410
Will Lytle
Umm.
1:0:16.750 --> 1:0:19.440
Will Lytle
So nobody knows any wiser that it was done by accident.
1:0:19.910 --> 1:0:30.280
Will Lytle
The other thing you could use is potentially some labels, but I'm very reluctant to to suggest that as a way of excluding that can have other impacts as well.
1:0:30.930 --> 1:0:31.330
Will Lytle
Umm.
1:0:34.580 --> 1:0:34.860
Speaker 1
OK.
1:0:34.920 --> 1:0:36.280
Will Lytle
But that would, I think, the deletion.
1:0:36.290 --> 1:0:38.550
Will Lytle
If you notice it's happened, just delete it and clone outside.
1:0:38.560 --> 1:0:39.800
Will Lytle
It would be the easiest for mediation.
1:0:41.480 --> 1:0:41.700
Speaker 1
OK.
1:0:43.430 --> 1:0:43.970
Speaker 1
OK.
1:0:44.210 --> 1:0:53.940
Speaker 1
Second, by met behavioral tickets without commits for one of our teams, they often lead to data fixes as opposed to code fixes.
1:0:54.410 --> 1:0:56.540
Speaker 1
Suspect that's messing bit of metrics too.
1:0:57.150 --> 1:1:2.130
Speaker 1
Does that sound like a kind of some kind of exclusive exclusionary status?
1:1:7.80 --> 1:1:9.330
Will Lytle
Umm, I'd have to look at it.
1:1:9.340 --> 1:1:15.760
Will Lytle
I I would guess that either, umm, if you're in live view it's either because of the status mappings.
1:1:15.770 --> 1:1:19.590
Will Lytle
I have the ticket is in progress but it's not in progress from a development perspective.
1:1:19.600 --> 1:1:26.10
Will Lytle
So you can do what I did just a moment ago, which is say that that status is A to do status for the purpose of live view.
1:1:26.400 --> 1:1:30.130
Will Lytle
So yes, it's technically in progress and design, but that's not meaning.
1:1:30.140 --> 1:1:31.70
Will Lytle
It's in development.
1:1:31.760 --> 1:1:35.920
Will Lytle
The other thing with the reference ability of course, is if you look at.
1:1:38.660 --> 1:1:39.60
Will Lytle
Umm.
1:1:42.720 --> 1:1:43.140
Will Lytle
Keyboard is.
1:1:56.800 --> 1:2:4.650
Will Lytle
So that the the our logic of mappings, as long as we're gathering the JIRA data and which we obviously are in this case and as long as we're gathering the repo.
1:2:4.820 --> 1:2:10.370
Will Lytle
So obviously, make sure that the repo is being gathered, because if it's not being gathered then that's gonna be the problem for as well.
1:2:10.780 --> 1:2:12.630
Will Lytle
Plandek will look at the commit message.
1:2:12.960 --> 1:2:22.500
Will Lytle
It will also look at the pull request title, the pull request description, the pull request comments, and we'll look for the ticket Key if we can map that ticket key to a ticket that we're gathering, we will link those two together.
1:2:23.370 --> 1:2:35.460
Will Lytle
This logic worth works bidirectionally, which means if you have no links in your commits, but ultimately you put a ticket reference in the PR title, the commits will inherit that.
1:2:35.540 --> 1:2:45.660
Will Lytle
If the commits are within that PR, and vice versa, if the PR contained, if the commit message contains the ticket reference but a PR doesn't, it will then apply that ticket.
1:2:45.670 --> 1:2:48.940
Will Lytle
If the committee is in that PR, then that PR will also pick up the ticket reference.
1:2:48.950 --> 1:2:53.690
Will Lytle
So we do quite a work bidirectionally with it, but with that being said, I would.
1:2:53.740 --> 1:3:0.10
Will Lytle
I would first check this just to make sure that there's nothing goofy, goofy happening there.
1:3:0.160 --> 1:3:4.170
Will Lytle
Secondly, just double check that the the pull requests are there.
1:3:4.380 --> 1:3:8.950
Will Lytle
If there are commits that you do think, hey, this is linked to this ticket, here's an example of it.
1:3:9.0 --> 1:3:12.620
Will Lytle
Show it to us and we'll we'll we can triage it, but it should pick up.
1:3:13.640 --> 1:3:16.670
Will Lytle
Umm should pick up of it automatically.
1:3:23.590 --> 1:3:24.600
Speaker 1
Anymore questions?
1:3:30.370 --> 1:3:34.70
Speaker 1
It looks like there's no Yep thing has been helpful.
1:3:34.80 --> 1:3:35.550
Speaker 1
I think this personally for me.
1:3:36.340 --> 1:3:36.850
Speaker 1
Thanks.
1:3:36.980 --> 1:3:44.600
Speaker 1
Thanks again view for your sharing and yeah, hopefully we all learn quite a bit from this session today.
1:3:45.920 --> 1:3:46.920
Will Lytle
Perfect. Lovely.
1:3:46.780 --> 1:3:47.90
Speaker 1
Right.
1:3:47.510 --> 1:3:48.60
Speaker 1
OK.
1:3:47.0 --> 1:3:48.270
Will Lytle
Well, have a wonderful day.
1:3:48.700 --> 1:3:49.100
Will Lytle
Speak soon.
1:3:48.140 --> 1:3:49.520
Speaker 1
OK, great.
1:3:49.690 --> 1:3:50.40
Speaker 1
OK.
1:3:50.50 --> 1:3:50.580
Speaker 1
Enjoy.
1:3:50.670 --> 1:3:51.860
Speaker 1
Enjoy the rest of your day, everyone.
1:3:51.870 --> 1:3:52.190
Speaker 1
Thank you.
1:3:52.870 --> 1:3:54.110
Matthew Frater
Thank you very much and bye.
1:3:53.970 --> 1:3:54.780
Speaker 1
Alright, bye bye.
1:3:54.840 --> 1:3:55.410
Iris Tan Ai Lee
Thank you. Bye.