 Hello everybody. I think it's about time we go ahead and get started. Thank you all for staying late hanging out with me this evening. We'll be talking about estimating for iteration with story points and then vertical slices. All of the slides and speaker notes are on a github page that is also on my github twitter and linkedin because that link was hard to deal with. I am T-Smith512 on those places and I work at Four Kitchens. So hop in right in. Four Kitchens uses Scrum to manage our projects and I think that estimating by complexity and building vertically are the two most useful parts of that system. Scrum is a process that follows natural development principles, focuses on quick iterations and delivery of completable usable functionality on a regular basis. If that's new to anybody, you do not need to already be an expert on that to be here. So a new project comes in and clients have really big wish list items. They'll call out big stuff like they want shopping carts or user management or a blog or some kind of big video library or will recommend big functionality like editorial workflows, access control. Those things are not directly actionable because they are huge. So let's call that an epic. A big ticket or story or large piece of functionality, it's not directly actionable or easily estimated on its own because of its size or its complexity or because it has a lot of moving parts. So what do we do with an epic? We break it down into thin vertical slices. I know it's late the day but I get punchy. All right, so what are thin vertical slices? Let's break that apart. What are thin slices? As it turns out humans don't estimate very well when the when something is very large. The precision of that estimate drops off as the size of the thing being estimated gets bigger. Also beyond estimation, it gets harder to collaborate on a big undefined blob of work. Also big undefined blobs of work is how scope creep happens because it's hard to put something in a red box. So a single ticket should represent a single deliverable unit of functionality. So we make a two list, we break our epics into actionable pieces. I like to frame them as stories. It's easier to think about what a user it's easier to stay in that mindset. If you think about what a user should be able to do when the thing you're building is finished. So by focusing on a user's desired actions, you can write thinner units of work and you won't prescribe technical solutions in your backlog and that gives your team more freedom to build things the right way the way they know how because you have experts and that's what we all want to give them the freedom to do what they need to do. And let's call that a user story and it takes the form as a blank. I want to blank so that an identified audience or user persona wants to perform a single action to accomplish a goal. This is not actually a scrum requirement. It's an optional extra that a lot of people use. And as for that persona, if you've done the UX work to break your audiences down into personas, that's great. If not, you can identify people that might use your website as a customer, as someone who edits content, you know, as a particular team or business unit, but a persona. So a simple example that's a little off topic. As a cyclist, I want to stop the bike so that I don't get hurt. We have a clear type of user identified, a single action and a clear goal. And this does not say anything about breaks. There might be many different ways to stop a bike or maybe you've got to handle bar breaks or you've got the like pedal backwards brakes that, you know, used to make me fall off my bike when I was looking. The three gotchas with user stories, use an actual persona. All of our placeholder tickets all have as a user, but I'm very skeptical of stories that start as a user. Because if you don't know who you're building something for, do you know why you're building it or if you really need it? Maybe it was something that marketing or legal told you you had to put on the website. Actions avoid technical prescriptions. And I'm really bad at this because I spend a long time as a developer. So I will occasionally write stories that are like laser focused on how I think something should be built in Drupal. I have not built a D8 site. I need to get out of that business or shift my responsibility within a project. And then goals. I've had a client that was really bad at this. Surprise functionality pops up in the goal. So here's a bad story. As a user, I would like to create an account during checkout so that I can see all of my past orders. We don't have an identified audience. There is technical prescription there because no one has ever wanted to create an account for anything ever. Also, which part is the new part? Is it the account process or the checkout process? And then the goal has a feature surprise. So something like this might be better. As a customer, I would like to save my contact information so that I don't have to enter it each time. This assumes that a rudimentary checkout process already exists. We have a specific kind of user. We've described what they actually want to do and why. And there's no technical prescription here. You could do this without accounts. So thin slices, we break down our epics into bite-sized pieces of work. We're user in goal focus. Consider user stories. Before I move on, any questions on this? So what about what makes them vertical? That is the top-to-bottom implementation of a deliverable feature. So that's front-end and back-end. That's content model and template, admin UI, front-end component. It is a slice of cake, not a layer of cake. So database, module install, content modeling. If a thin slice is a small unit of functionality, the vertical is everything it needs for it to be useful. So push past or push back. Because everyone's going to agree that this sounds like a really great idea. And then as individuals, they will go silo themselves and you'll end up with front-end components that aren't hooked up to anything or UI elements in the admin that don't have a front-end effect or some kind of big integration with another service that doesn't ever get used. It's a team effort. If a ticket is not usable, then it's not deliverable and it's not valuable to your client. And I think what's really hard for people to wrap their heads around sometimes is that this is not actually the most efficient way for an individual to work with perfect knowledge. If a project is never going to face any shifting requirements or changes and you've only got a team of one working, this is kind of inefficient. It would be a little easier for somebody to just go make all the content types and then go make all of the views. But then you've got somebody running around the code base and you've got a whole bunch of things started and very few things finished. This process means that not only is somebody going to have to be focused around building and delivering value in chunks for your client, it also means sometimes you have to be okay with rework or when requirements change throwing something away and remembering that everything that is in this sprint was deemed more urgent than anything that is not in the sprint. So here's where my colleague, who I had a lively conversation about this this morning, is not here. So where this happens at Four Kitchens a lot is we discuss whether there should be separate tickets for front end and back end. I apparently have developed strong opinions. I like tickets to be focused on user and value because if you split tickets it'll split the team and it can be harder to track progress because you have a bunch of little things started and then you end up with, you know, you have to make sure that you have a ticket for every little piece of something that you've got in progress in the upper. But multiple people can work on a ticket. So here's what happens. If you split tickets you have back end and front end and as we've moved to more component-driven design and my colleague's point this morning was front end actually is working first now. So I might need to reverse the image here. We'll have a bunch of front end components that are built out before the back end catches up and in the delta there if there are changes then we've got to track the rework that has to happen. And this looks a hell of a lot like waterfall. You know anytime you can put something on a GAMP chart is not necessarily a bad thing but it does make me worry about how it's going to be adaptable to change. But we have tools that help with this. If you're using JIRA you can add extra columns to your board. Here we've got, you know, from to-do, I've been asked to also describe the content of images. Back end column and a front end column and then the done column which you can do in JIRA. You can do that in Trello too. I think you can do that in a bunch of different tools. Never heard of it. Let's talk. Good. Or you could use subtasks. So JIRA will keep the parent issue of all subtasks open until all of them are closed. But then a subtasks can happen. It has its own status and it can move independently of all of the others. They just can't close until they all close. So then vertical slices enable your team to be more iterative. It keeps the team in sync as they're working on the same areas, divides big work into deliverable segments and it reduces waste as requirements change. They're in fairness. There are exceptions to every rule. Sometimes it does make sense to build things horizontally. Like if you are planning a big migration and the migration has to happen first, you might- I mean, you know, this is where you're going to need all your content types built. Or if you're doing a huge content rewrite, maybe you need editorial tools first. But it's really important that you have to make sure that you account for every layer that you haven't built for every feature you touch. So one of the things that I want us to start talking about internally is maybe migrations don't need to be first every time because it messes up this flow to have migrations be first. Open conversation for us to have. Maybe next year I'll have an update session. Actually, before I move on, any questions about any of that? I prepared for many other questions. That one's hard. And we have been evolving our process for years to try and account for that. When I first joined Forkitchen six and a half years ago, there wasn't design ahead of time. Design happened during build. In my opinion, that was not our strongest design process. We do some design work up front. And it does follow a bit of a waterfall. It's a waterfall of agile hybrid. We'll start by breaking down the content types we know we're going to need through UX research and study with our clients and then start working on designing components. They'll be wire framed. And some of that is design in the browser. So there might be components that live somewhere as HTML prototypes and the development ticket is, okay, pull that out of the design deliverable and make it work in a Drupal component library. Our open source tool in Mulsify greatly helps with this process. And I am not well suited to give the sales pitch on that tool. But come by our booth and check that out because that helps make some of that mesh together. But yeah, there is... I don't have a perfect answer for that because we're still working on it. But it usually involves design work ahead of time, but then not completely implementing it and calling it done until it's driven by something. Does that help? Anybody else? Related to the user story, how do you frame that? Are you writing the user story before design? Absolutely. Those two things happen at the same time. So in four kitchens, we break our projects up into... I don't want to mess this up in front of two colleagues. We've got after our business development and sales process, discovery, which is what are the problems we're trying to work on here? Definition. This is how we're going to solve the problems. Then design and architecture. And that's when the backlog of user stories gets built out. Somewhere in definition and design and architecture, we're starting to make lists of epics. And epics are being broken down into tickets with user stories. And because so many clients think very well through design deliverables, that process is they inform each other as you go. So how do we estimate these slices? We don't use hours, we use story points. Because story points allow us to estimate by complexity. You estimate the relative complexity of a task. Rather than the time someone thinks it would take them to complete that task. And why do we not estimate hours? Because I write CSS and you write modules, we're not going to agree on the hours. And do hours include hours for requirements gathering code reviews, deployments, tests, rework. And if a task is estimated at three hours, what happens if it doesn't take three hours? Is your client going to get irritated because you do on a particular task wasn't nailed? Or are they going to start assuming that you over or underestimate everything and build that into their expectations? But we can agree on complexity. So you and I can both agree that adding and theming a link field on a page is probably not very difficult. But adding a taxonomy powered fascinating to a solar search scares me. I can't tell you how much a motorcycle or a car or an airplane weighs, but I can give you the order. And from there we can extrapolate a timeline. So the velocity is over time the number of story points the team can build in a given work cycle. And that will tend toward an average. And it's less granular than hours, but it's usually more accurate. And if you know that the team is going to work a set number of hours in sprint cycle, you can estimate the number of points they can complete. And in scrum teams should commit to a sprint they agree is realistic and then work to meet that commitment. And that helps you build a schedule. Most of the time stakeholders are more interested in when a particular feature is going to be delivered than how long all this stuff takes. And then knowing your team's velocity and story sizes, a product owner can make more informed choices about what goes into a sprint and how that prioritization works. Do you want four motorcycles, two cars or an airplane this sprint? Don't share your math. So by now all of our project managers have discovered that if you divide your velocity by hours per cycle, you have points per hour. And that can be a useful number to have in your back pocket when you plan stuff. Four kitchens bills by the hour. So we allocate all of our team members by the hour. So this is a number we use a lot. But keep it to yourself because as soon as you start talking about that with your development team, we have team members that will start using that as an hours multiplier because sometimes these sizing conversations can be difficult. Is this a three or is this a five? And what you want is this is a three because it's really not harder or easier than this thing I did last week. It was also a three. What you don't want is well, you know, a three really means that I could do it, you know, sometime in the morning. So it's a three because that means you're trending back towards estimating by hours. And how does this happen? You can use planning poker, which is if you Google that, that's like a Scrum Alliance, like actual trademark name spreadsheet reveal where everybody types a number into their cell on a Google sheet and hits enter at the same time. You can shout things out, you can hold up numbers. Whatever works for your team, but the team picks the size, not the PO or the stakeholders. And the Scrum Master is there to help facilitate not just the meeting, but also comparing stories to previous stories to help arrive at that size. If a team feels kind of stuck on something, that person can kind of prod them on well, you know, is this easier or harder than adding a link built to the page. The PO can ask if there's a way to trim complexity so that something would be less complex to build, but the PO cannot dictate the size of a story, nor do they get a vote. And we use for the math geeks pseudo Fibonacci numbers to size stories. This is just a scale that accounts for uncertainty as science. One reason that we broke ethics into thin slices is because humans have a hard time estimating the scale with precision and this applies for story points too. So we have one, two, three, five, eight, 13, 20. And shirt sizes can help sometimes if the numbers are a problem because eventually you're just going to have to stop saying points are not ours. We've all had clients that have a hard time detaching that, especially if people are coming and going from those stakeholder meetings. So, you know, a small is a three, an extra large is a 13. I don't like it as much because it means that the project manager is sitting there like converting words to numbers as they go into JIRA, but it can be helpful for some clients. 20, 40, and even 100 are valid estimates and that's the sign that a team should break something down before trying to get started on it, but we will use things like 20, 40, and 100 to placeholder ethics. So maybe there's a 40-point bucket for the blog and there's a 100-point bucket for the app. One is very easy. It's check one box, change a field label, nothing is ever a one, which is why two is valid. 20 or 40, that's an epic, break it down, not pictured 24, 800, but encourage your team to pick a size by comparing scope of other stories, not time estimates, and then stick to those sizes. It's not a six, it's not a 10. Don't use the numbers in the middle, round up to account for complexity and unknowns, and round down if you want to put boundaries around the complexity. I should not use time box because I'm talking about how you shouldn't be using hours, but if you want to say, don't make this a 13, we need to do a lightweight implementation of this, this team can agree, okay, let's find a five-point way to do this. And then don't change the size retroactively if something is easier or harder than it was anticipated to be, because that trend will be worked into your velocity over time. I've had teams that just everything's big, everything's an eight, everything's a 13, and they get a million story points done every sprint, and then I have teams that estimate two, three, and five for everything, they get a couple dozen points a sprint, and that's fine because it's not hours, just the scrum master knows and the PO knows, this is this team's velocity, based on the way they estimate and what's in the backlog. Oh, actually, and to add, I've advanced the slide and the speaker knows you're not. Also, by making sure that you don't change the number, you can use that as a litmus test during revisions on something. If something comes back, the client doesn't accept the story, like, well, this was an eight, and what you're asking for is very complicated, it was not part of our original estimate, let's revisit, let's separate the story out, let's make a modification in the future, for sure, we can pull that story into the backlog again, change the size and start over or extend what we've started to build, but by keeping the size the same, that helps you guard against just gentle scope creep that happens in meetings. Any questions on story points? Okay, how can our tools help? A sample workflow and reports from JIRA that I find very useful, talked a little bit about subtasks, this is useful to split the layers of a ticket. Subtasks track through sprints until the parent closes, so you can complete individual pieces and they'll sit in the done column as your sprints roll forward until that parent is done. You can assign each different subtasks to different people, and they can each have different statuses, and they all have their own detail view and comment threads, so that's very powerful, and I really like subtasks for that reason. Columns add workflow steps, and this is useful if every ticket needs the same steps in the same order, or at least most of them do. Team members can remain assigned or they can hand off as things progress through, this can get messy, we had a client, I was the CEO of this project, that had many columns, there was a to-do, needs info, which I have huge asterisks around that, because if something needs info which should not be in your active sprint, in backend, ready for front-end, in front-end, code review, PO review, client review, and done, but it worked for this group of people that's what they wanted, and I aim to please with JIRA. And then what you start getting is things like a velocity chart, and this will help you visualize how fast story points are completed. This takes, this gives you a timeline of sprints, points committed in gray, and points completed in green. And you can see that this team, after the first sprint, was like in the 50 to 60 range, and they weren't meeting their commitments, and they said, all right, man, for this sprint, five, we're just going to load it down, and we're going to buckle down, we've got a ton of work done, it's going to be great. So they committed to an insane sprint, and they completed their velocity. Then we started adding more team members, and you can see the green increases. The version report, which I think is really awesome, and I'm going to have to read this very carefully to make sure I don't screw it up, shows a timeline of unsized, sized, but incomplete, and sized and complete issues. And it draws a line from zero at the beginning of a release to the current number of completed points at the current date. So that's kind of like a burn up chart. But then it extrapolates out using current optimistic and pessimistic rates from, you know, based on current progress to the total number of points in a release. So all of this ends with, and it results in an estimated date for the release. Was that a lot? That sounded like it was a lot. So what it's, and I wish that I had one that wasn't completed, but you can see that blue line follows up from, okay, this has been a long time ago. So we were burning up our completed points from October to January. So that's the blue stacking that's increasing. And then I think we cut the project, and that's why it kept drawing out. And then you can't see the width of the lines above and below. But the guidelines would show you, based on your current velocity over time, when are you going to finish this stack of work that you've added to the release? And there's the copy of what I just read. The release burn down is a little bit easier to read. It takes the same data, but it does two things differently. It shows scope creep very obviously, because that's the green increase along the burn down. So any points you've added to the release show up as this green box on top. So you can see, well, yeah, we're making progress. But like, it we're kind of working our way backwards, because every sprint, we're still adding more stuff to the backlog. And then instead of giving you a release date, it gives you a release number of sprints. So it will say your current velocity, you've got this many more two week segments you need to complete this pilot work. And you get all of this for free if you use story points and vertical slices and a regular sprint cycle. We use two weeks, most teams seem to use two weeks. That works well. I've seen three, one and four start to become less useful because either you're like turning around all the time, or you've got a really long time for things to go a little sideways. And you can do this in any tool that you use, or you can do this on paper or with a spreadsheet. The hard part is maintaining an estimated backlog. And that's huge, but the payoff is also huge. I made references. This presentation is just a synthesis of storypoints.info, which I use for teams and for clients to explain what story points are after I said points are not ours too many times. And then I have a video, what are story points and what are thin vertical slices. Those are all linked from the slide repository. Thank you for joining. I'm T Smith 512 in a bunch of places. And we have information about please rate and review the session and the conference at large and join us on contribution Friday for these workshops. Any questions? Mm hmm. Wait, or I can repeat it, but hearing it from you would be better. I have been encouraged to make a new explainer video about exactly that question. It would be so great if we did have that. And because we operate as a consultancy on fixed scope projects for the most part, we know where it's going to end. But what we'll do is break out ethics slowly. Like we're not ready to get started on that 100 point epic. We might leave that 100 point epic ticket in the backlog and it's way far down. So we're not going to pull it into a sprint, but at least it has those points accounted for for use later. And then we'll also break that down. That might be, you know, a couple of 20 point stories as we get a little closer to understanding, you know, what's going on, but we need, you know, more time as we go to break stuff down to keep backlog rooming moving, meetings moving. Sound good? Thank you. One of the challenges that I would like to solve is like how can we either have like table teams or a project team. Yeah, as we have multiple projects, which would rather be in an agency environment, how do you assign the team to the project? Yes. About every 18 months, there's a big like, we should do stable teams at four kitchens also. We haven't made that shift because of the size of our organization, but I feel like we're going to get there eventually, because of exactly what you mentioned. If you have stable teams, their estimates are going to be pretty predictable, even across projects. Whereas if you've got our current operations, sounds like what you're doing, every project is a new group of people and they will estimate together differently. And so it takes a couple of weeks or a couple of sprints to start getting like really good numbers because of that. And because of that, that's why we're thinking about maybe moving to stable teams. Our support department does operate that way. They have some, they don't use story point estimates for a lot of things because of the way their business unit operates, but they do have stable teams because it's one support group maintaining all the sites that they support. And when they estimate, they get the benefit of, yeah, this client's been with us for a week, but we've been working together for a year. Certainly for this kind of estimating, stable teams do help. Two more questions. First one, how do you account for experience with story points? And then especially if you're kind of doing this in a democracy type of situation. Second question, how do you feel about the silence on user stories tasks? I've been reading, there's a lot of, you should not have one person inside, so, you know, single tasks. So at a high level, I absolutely agree with that statement. But that is up for debate among teams. Let's go in order. Number one was experience. So, and that's why I would stay away from hours because you're very experienced, and I'm not. You could get something done in three hours. It's going to take me two days. So one of the things that I did, I am driving a screen I cannot see. Storypoints. I don't know why I'm getting security warning on that. Anyway. Oh, because it's a Google paid GitHub pages. So with all of this, I went through when I made this, our JIRA backlog across all projects and just started pulling tickets for sizes. And while you and I might disagree on how many hours a particular feature might take to build, if I can read any of those, adding a view of content with a couple of options that we can talk about. Even if I don't know how to do that, that might be something I can see as that doesn't sound any more complicated than last week when we added a new content type. But we would also probably tend to agree on, you know, we have this huge migration coming from, I don't know, something in Visual Basic. And it's going to take a million years. It's like, okay, that's going to be, you know, a 40 point story. So that's at the high level. And then what it really gets down to is if you and I are not sure about something, you really know this area. And it is a five. And I don't know this area. And I really thought it was an eight. I might say, have you thought about that, you know, this CMS only runs on a 30 year old computer. And have you thought about how there is images that are in line in the content, but they're hot linked from some other service? And have you thought about all these things? And you say, yes, I thought about all these things. And I know it's five, because I do work like this. All right, you win. So the discussion among the team is why the team works together to size stuff. That's part of the process. And the next thing you asked was assignments. Scrum and agile methodology generally would propose self guided or self managing teams. So they should pull the work out of the sprint backlog as they go. And they should always pull something from the sprint before they try and pull something that is not in the sprint, which means like maybe if there's only one ticket left and I'm the one with the free time, I might be doing something outside of my wheelhouse. It's only vaguely related to what you asked. But team members in my opinion should assign themselves. Now I've worked with tech leads on projects. The way we structure, there's usually like one technician who's assigned as the tech lead of a project. If that person wants to assign things, I'm okay with that, you know, air traffic control, but it should not be the scrum master or the PO who's assigning tickets. Thank you all for staying over. It's been great and I'll see you all tomorrow.