 So let's start. Good morning. Hi, everybody. If you're in the Scrumberjack session, this is the correct session. This is about prioritizing your Scrum product backlog and Drupal work. And my name is Amy Dugnan, and we'll talk a little bit about that in a second. But first of all, this is a lot of information. It will be fast. There are a lot of slides. These slides will be shared, and it is recorded. Hang on for the ride. It'll be fun. So first of all, who are you? Who's a developer? Okay. Project manager. Lots of you. Product manager. Ooh, not so many. This is good. Executive. Okay, good. How about everything? Okay. Great. Yeah. A lot of jack-of-all-trades here. What size of work do you do? Do you do, like, small brochure sites? Not that many. Just one or two. How about medium sites? Okay, we've got a few more of those. How about with some integrations? It's not huge, but it's slightly complex. How about large enterprise? How about ginormous enterprise? Yeah. Okay. Good. This is what we're going to talk about helps all of you. And this session, if you're a developer, a basic goal is, like, how to get the business to agree to upgrade core. And if you're a product owner, like, how do you align the development team to your business needs? And as a stakeholder, is how do you actually request some value-based features? And we're going to be covering a little bit about Agile and Scrum 101. We're talking about understanding and defining business value and how to define and prioritize work and a little bit of application in real life. So that's a lot of juicy topics, so we're going to go fast. Woo! So first of all, why Scrumberjack? Well, you can see that the evolution of web development is moving a little bit toward a lumberjack look. And what does a lumberjack do? Well, they work with forest trees and logs. They cut wood. They make lumber. But they work hard and it's an ongoing effort. And why Scrumberjack? That's you, Ryan. Why Scrumberjack? Scrumberjack is punny. And this is my backlog and I'm full of bad puns and it will be punny hopefully through the day. I have not had that much coffee. That's good for you. Scrum has backlogs. Lumberjacks work with logs. And Monty Python, I'm a lumberjack and I'm okay. And then Drupal is created by Scrumberjacks, which you'll see throughout the presentation. So first of all, let's talk a little bit about Agile and Scrum. First of all, Agile is a philosophy of iterative development. It is not how you do it. Scrum is a framework to manage and execute that iterative development with high value solutions to complex problems. Let's demystify this. How many people have heard people go, yeah, I work Agile and Scrum and they don't know the meaning of the two and they'll inter-swap it. Yeah, this is real or you'll go to an interview or you'll hear maybe a potential client or a business owner. They'll like, yeah, we want to do Scrum or we don't want to do Scrum but we want to do Agile. And you're like, whoa, okay. So it's funny but it's real so let's just walk through but this is a little bit of the difference. And the first reason that Scrum actually exists is it's created to overcome the challenges of a waterfall project and software development projects. And really because people were saying, will this project ever ship? Is this project ever going to end? Are we building the right thing? The developers ask and then the business owner is like, what is the dev team doing? And the dev is like, how the heck do I estimate something that I don't even know what you want me to build? So you have all these questions that come up in a classic waterfall-based project because you have just one section of design and implementation and one round of verification classically. You can work more into it but that's kind of the base of what waterfall looks like. So Scrum works. Why? Because it didn't do my thing. Scrum works because it limits work delivery to a short finite period of time. People can pay attention to a two to four week sprint. It uses a well-defined work management structure. It uses a well-defined meeting structure and value is often tied to delivery. It's a valuable product. And developers get it. It's short. I can make things. I can see me make things. And it's great. And Scrum is lightweight. And it's simple to understand. You don't have to recreate the process all the time. It's there for you. But it's incredibly difficult to master, right? Because it gives you a framework but it doesn't tell you how to do it every day as you apply it to your job. And that's what we're talking about today. So if you visualize it, Scrum 101, the old school way is you have product backlog, sprint backlog. Perhaps a sprint is every two weeks. You have daily stand-ups. And then out of that two-week iteration, you have some potentially shippable product increment. People like to say minimum viable product, valuable product, visionary product. A lot of people are playing with the terminology but you get something tangible out of your work that was well-focused. What's really important is we're going to talk about backlogs. So what is a product backlog versus a sprint backlog? Really, as things evolved with Scrum, people have figured out, oh, wow, the development team needs to work with the product team a little bit to kind of understand what they're asking for and how prioritize. And that's now called story time. So let's talk about what you want. Let's see what those impacts are and allow more discussion with the product's teams. So first of all, who is... Is everybody familiar with the term backlog? Yeah, sprint backlog? Okay, good. Let's clarify this a little bit more. So the sprint backlog is all the work defined for the current sprint cycle, whether that be one week, two to four weeks, anything. It's small and it's easy for the team to see and understand and work with. And I put an asterisk on this one because people don't normally say this, but we prioritize our sprint backlog each week by priority of what's the super most important thing that the business needs in that delivery but also by skill because we have some complex projects that some tasks can't be done by one person and the team. So we make sure that the work is evenly balanced. And the product backlog, that's like all the work for the whole product. That's like how many weeks in the future? Like years? It can be quite large and menacing and it's supposed to be prioritized by this person called the product owner. And I only saw like two hands raised when we talked about what a product owner is and who resonates as a product owner. So we'll evolve that a little bit. And so that's why we're talking about the product backlog. Because the sprint one's pretty tangible. So what's in a backlog? We have well-defined work requests in something called stories. And work is often categorized by size. There's different sizes of tree trunks in a big thing of wood. First of all, they have a topic, a type of story called an epic. And what we've defined it further functionally is something that, an effort that will span many sprints. It's not something that you can do in one sprint. A story is a functionality that can be built in the sprint. So in whatever sprint duration you have, your functionality can be built in the sprint. And tasks are just the steps to actually execute on that story or function. The sprint backlog is limited to the work the team can finish. It may be a combination of different work sizes. You might have a very large feature and a couple tiny ones or a ton of tiny ones. And it contains well-defined work requests. If you do not have a well-defined work request, maybe the defined work request is to please further define this work request. And actually that's a very valid thing to do. It's the plan, it's the please R&D, what the new big effort is going to be. That itself is a story. And then the product backlog is everything else and that conceptually is huge because those things can have elements of just initial ideas or aha moments or very limited requests from the business all the way up to very well-defined efforts and maybe pre-scoped project work. So it's hard actually to see what's going on if you have that range of information in your backlog. So some of the product backlog challenges, it's like what have you experienced? Who has very large product backlogs? Yeah, quite a few. Who's disorganized or they get a disorganized backlog and you're like what? Yeah, a lot of them. How many are prioritized correctly? We got a few of them. Yeah, so you can see the story we're building here. There's not that many are prioritized correctly and it's ongoing challenge because a lot of the things they may become out of date are not relevant because it might have been important a month ago or two months ago or six months ago but what does that actually mean now? And you may have duplicate requests. This happens all the time. Somebody says something in a different way and you're like why do I have these five requests that look the same thing? So it's a lot about intake of new work as well and knowing what is in the backlog. But if it's a huge mess, it's going to be hard to find those things out. And a lot of this ginormousness and lack of organization or structure is not clear to developers and everybody would be like don't even make me look at that because when part of Sprint is like oh yeah, you're done with your Sprint, there's nothing out of the backlog to work on. And it's like oh really? Do I have to go into that closet? All this stuff is shoved into? I'm going to open it up and everything's going to fall out. And so it's a bit scary. And then also they're like half the time, it's like I can't tell from this backlog what I'm even building, right? It's a big disconnection from what really are you doing and it's more wood cliches. You can't see the forest through the trees. You're like swamped with so much detail that you don't know that you're in the forest. You just see lots and lots of trees. And what is that forest? Where is my forest? How important is the forest? So if you're in the position that you have to help clarify and clean your product backlog, well let's just start from scratch. Just get rid of everything. Yeah, I'm nervous laughter. It's a good one. Yeah, but what happens when you like clear cut and then you still can't see the forest and then you still don't know what's going on but now you have no trees, you have no other value within your backlog. So what we're going to do is talk about seeing the forest purpose and describe each tree's contribution to the overall forest. And so we bring chaos to order from a disorganized backlog to an organized backlog. And the product owner's role in all of this is to see value in the work and align it and organize it. This surfaces through a categorized backlog that can scale across functionality and scales to a long-term product roadmap. It may take some effort but if you have the right tools and knowledge, you could be master of the backlog. So this is awesome. This is my backlog. So like the thing that's taught in all sorts of different places is that we, like how do you actually define value? And it's interesting, I think some of my slides are missing out of here, but that's okay. First of all, oh yeah. Okay, so by default, they resorted my slides for this right before they switched it to the layout. So let me see what's going on. So first of all, let's talk about product and business value alignment. So let's all talk about assumptions because I'm a project manager and I'm going to set up some assumptions for this discussion. But first of all, let's understand we have to make money to spend money or provide value to get foundational money to spend money. So first of all for this presentation, a product is equal to a Drupal website that is tied to a revenue stream. Stakeholders are multiple business groups that have interest in this website. The business makes money from this product. The business pays for website development that you are responsible for. The business needs visibility to website investment. The business defines the value of the work and the business value drives prioritization of work. That sounds totally simple, right? But like how is value defined and what items are more valuable than others because as we go through prioritization challenges, who has a squeaky wheel that's just really loud and like I need that feature and it might be the stupidest feature ever or a very wonderful feature but not very important to the business. Also how about those that I've got Power, Prestige, and the Pocketbook? These are people that's like, I don't care, make this, I am paying for it. And how about the conflicting priorities? Everything is a P1. Okay, yeah, that one's more... I see the team over here is hilarious. And a lot of times people exclude maintenance like Drupal product patches and everything. And who has like the constantly changing roadmap, right? And what I do is I feel that sometimes if you're on a larger site or you're on a yacht, or you're not on a yacht, you're like on a princess cruise ship. I think there's somebody from princess in the room. But you're on a cruise ship and when you change priorities, it is very hard to turn that cruise ship which could be a large development team. It takes time. It decreases throughput from your team. So if you have constantly changing priorities that are radical, it's a huge impact to what you're doing. So we had, you know, that when... This is tiny, okay. Sorry, we made it 16 by 9. So the first thing for defining value is... I'm gonna just tell you what it is. You make money and provide value. You start there. Two, you invest and on improvements to making money and buying that value. Three, you paid the rent and keep the lights on. You have to maintain that and maintain the basic support structure. Four, you have to have data and metrics that say, yeah, these things are either working or failing. And those things you have to look at in a feedback loop. You have to look at it and make informed decisions to actually create and expand your product backlog. So let's talk about the primary value creation. First of all, you have to make money and provide value. And if we can imagine this as kind of a conceptual section, you first, you have to market your product. You have to have a customer shop for your product. You have to then sell the product. Then you support that over time. All the while you have a large group of content supporting this. What this looks like in the real world is you have a blog that surfaces information through social media and SEO. You have product pages that inform the person about buying your product. You have a shopping cart that they can actually buy things and then you have a contact form for help and support. So that is making you money. So at the bare minimum, you should be able to run your business, right? Yeah, that's it. That's all you need, right? But no, that's not all you need. Because you need to have an ongoing improvement to primary value to improve your business. And so then you have this idea of supporting systems to your revenue stream. And they provide direct impact to value. And that's important to understand, because the first one is the most important, let's make money. The second one is let's make more, more money. We're talking about let's make more, more money better. So if we can visualize a supporting system in this model, you have SEO will help market your product. You have targeting while the user is shopping for related products and products like these. You have a very secure shopping system so the person will buy the product from you because they feel safe that you can provide a good secure system. And maybe you have something like onsite search that has a lot of knowledge based articles or anything that supports your product over long term in a very business savvy type of way. And underneath that, I would say performance is a supporting system because you need to have an engaging fast system for your end users. And if you look at it in the real world, you have keyword, so perhaps like features within each one of these would be a keyword enhanced URL pattern for SEO. Maybe you are doing some A-B testing for targeting and then you've added single sign-on for security and shopping carts. And then perhaps maybe you've added self-service support or documentation for your product. And all the time you're reducing page loads and you're avoiding white screens of death due to performance lags. So let's expand this idea, right? We are making our money, we're making it better. And then, but they're sitting on a Drupal site, right? It's sitting on infrastructure and stuff happens. And so we have to maintain our basic needs and keep our lights on and pay the rent. So if you can visualize this, a couple of types of supporting systems are software updates and infrastructure updates. And has anybody heard of Drupal Geddon? Yeah, that little thing, yeah. How about the heartbeat patch? The heart bleed patch, I can't talk this morning. How about the log jam open SSL security thing? Okay, yeah, that was a fun one to find. Yeah, so this stuff happens and it happens in business and you can plan for these things and you can plan for contingencies, but they do happen. So let's go on. What next? Oops, I did the wrong button. Okay, here you go. We're at the reporting and feedback loop. So at this point, you have to retrieve and review data about these major processes and features that you've put out because you don't know if they're doing well or not. So out of each one of these systems or processes, you capture metrics. So like for primary value creation, often it's like how many number of visits to the site? How many leads are you generating? What's the number of sales and conversions you have? Supporting metrics for the supporting systems could be like what's your page rank for SEO? What's your site speed? And also metrics for the supporting systems, it's like what's your version? What's your uptime? How's your performance? And all of those go into a reporting and feedback loop which is looked at by executive leadership and knowledge owners and product owners because they can say, oh, look at the thing that we did last week has really improved our page speed. And they can validate the decisions that they've made in development and then that makes everybody feel good. And if you look at that in real life, you have things like sales reports, Google Analytics, Versions, is your Drupal status page red, that type of thing. Even the tiniest tangible bits of metrics are really valuable to start tracking. So the next piece is the product roadmap and backlog. So you've got all of this feedback and you're like I need to now make informed decisions and invest in change moving forward because I need to make more money or make more and more money. And I also need to keep the lights on at the same time. So this all pops back in out of the reporting feedback loop into the product backlog and through these creation streams. And it looks like that. And really you have to go, well these all seem really important, right? Who thinks every one of those things on that screen is important? Actually that's not that many hands which is funny. But I see strongly waving ones. When you work in big complex enterprise crazy sites they get more and more important and you have business units that have their own budgets and things and they get strongly important on every level. And then they're conflicting because they have the same amounts of budgets and maybe the same amount of cloud. Like whose VP is going to go ask the other VP to like step down. That's interesting. It's an interesting time. But it all work types are necessary and some efforts do take priority over others. And the priority may change over time based on the business and the scrumberjacks help navigate those changes and make informed recommendations. So all of you here as developers or maybe project managers that aren't the quote-unquote official product owner or the business owner of the site this is where you can help influence change by how you structure the way you capture and organize your work requests because it's like a Grassworks Foundation. It's like you have to start the structure and hope that they kind of jump along for the ride and it takes some time. So the first thing is let's talk about the number of hours in a day or in a work week or sprint. We're going to talk about balancing work and this is another scrumberjack from Drupal. This is John Peck, Flux Sauce. And he's balancing his daughter Genevieve. But really when we're balancing work you have to account for just overhead of stuff. So the scrum, meetings overhead, administrative overhead, people have time off, that type of thing. But this is a very fair kind of way to balance work. 15% for reporting and feedback, 30% for primary value creation 25% for the direct supporting systems 10% for updating patches. At least it's something. Now, these are flexible as the business needs to change. And they're also flexible as Drupal Gettin happens or Heartbeat happens. It has to be flexible across all of the different work streams but not to cause undue technical debt or really cause problems for the business. So, yeah, this is what it looks like as it's full here. So we have 30% for primary value creation 25% for supporting systems and 10% for software updates and 15% here. Now, that's product backlog management can be kind of clumped into that 20%. In real life, sometimes you have work stories that are saying, please define requirements or please design something. So that's where it's like, well, that could be arguably backlog management and clarification but whatever, maybe you just need time allocated from people that are in the 30% value creation system to actually do the work. And play with that balance there. So if you look at balancing the work and it's sample work applied to one sprint. So your 20% overhead is having stand-ups, sprint retrospectives, your reporting and feedback loop. Perhaps you have a create a page speed reports per page type. And that's owned by Roger Reporter. And the primary value creation stream, they've said, I want three important things. I want a blog content type form. I want the blog content type display or theming. And now on my cart, I want to update the checkout messaging to say, yes, you bought it. It's awesome. Thank you. And that is three people. It's Barry Builder. It's Cameron Commerce and Debbie Developer. So you have Skype Builders, Commerce Specialists and Frontend Developers. And then maybe you have to actually add some rich snippets to product pages and implement custom analytics. So you have Samantha SEO, and Roger Reporter is going to come back in because he really knows his analytics well. And then you have your supporting indirect work. You know that there's a supporting core security release because thank you Drupal Association and thank you Drupal project team for having a pretty set cadence of when you do feature releases and security releases. So it's very nice. And that's what Debbie Developer works on. So you can see that the team is distributed based on their skill and the work priority. And if you get into balancing work on the big picture, this is things called the business roadmap or the project roadmap. So who's classically trained here as a project manager for like waterfall stuff? Yeah, there's five in a room of many. So quickly a project is an execution of effort with a finite end over a period of time. A program is in multiple projects aligned to like one or many business goals, but they're managed as a group and a portfolio is something that exists over time. And the portfolio is very similar to looking like a percentage based balance system of work. So if we move back here, a lot of people will have roadmaps that will show programs, projects, or basically structures of a portfolio. So if you look at this, this looks kind of like a portfolio at its simplicity. And so you can see the reporting and feedback, they have different stakeholders and they have prioritized that the page performance reports come first and then we have a next thing coming up in their priorities backlog for cart updates and feedbacks. So, and you can see the primary value creation has work going through time. They have more percent, so they have a lot more efforts going through. And this is very real. This looks exactly like business roadmaps. This is real. This is super helpful because people, when you talk to them, resonate with timelines and clarity. If you show them a list of just all of the tickets in your backlog, like in JIRA or an Excel spreadsheet, they're going to be like, what? So this is helpful to communicate down to your developers or with your developers, not down, and then with the executive team and product owners. So we're going to apply this to a blog. So we're going to take one feature and we're going to evolve it. So the blog at the very beginning, there's an executive, it's like, why are the number of sites low from our reporting and feedback loop? And then they get a competitor analysis outcome and they said, well, all of our competitors have a blog and we don't. And they're popping it out on social media and that's taking our visits away. So he goes and talks to the stakeholders. Then they go, oh, we need a blog to be competitive and increase our traffic. And the product owner of the website says, oh, the business needs a blog. How big is the effort? And the development team's like, I don't know. What do you want? And so they do it. They go, okay, this is probably going to take more than a couple of sprints because we have to start from the very beginning. They make an epic. And then there's a little definition of tasks. One story for each which is defining requirements, designing the blog, building the blog, write content for the blog. A lot of people forget to do that. And then go live with the blog. And if you see this in the sprint structure, here's sprint one and I know it's small but I'm going to talk you through it. Sprint one could be defining the requirements and you can assume like two weeks is a very aggressive time in large enterprise that people A, give you requirements, B, give you feedback and that type of thing. So that sprint one is just getting the business input. Then sprint two is design the blog with the graphic design. And assume maybe they want it fast. You have to do it on, like do all iterations in within two weeks. And then you can start building the blog for the content time because you know the fields that you're capturing. So you can start development very early. And then sprint three, you've got a lot of stuff going on. You're building the blog and you're going to build the blog listing pages and you have views. And you notice that the views module has a security patch. And you're like, hey Scrum Master, I have a security patch. Can I update the views module at this time? And you say, yeah, we don't have a lot of views on the site. It should be low impact. Let's do that. And then at that same time, the designer is theming that blog. And you can do a parallel effort for people to start writing the blog content because it takes a while to write and get that approved and edited. And then hey, maybe we're going to start adding that blog content type to the search engine. So do you see how we prioritize the basic form and data structure first? So you can start doing lots of rapid parallel development. That's really cool. There's a lot of stuff going on. Then you're in Sprint 4. You're tuning the theme. You're getting the blog content approved by the legal team. You're populating the content into the site. And you're training the business on how to actually do ongoing blog updates. So that does take some time to prepare. And it all comes out of your Sprint team's effort. And then possibly Sprint 5, you go live with the blog and you still, and you track the logs and stats. And that's where you start looking at metrics. Now what happens is you have this wonderful iterative check-in point at each end of the Sprint so you can make micro-corrections based on business education, business changes. Maybe they want to track some other metrics that need to go along with it, that type of thing. But you have constant check-in. Now this looks like a waterfall-y thing, doesn't it? It looks like it's iterative. It looks like it has dependencies on previous work and work planning. Yes, it does look like it. But what waterfall has less of is iterative check-ins to make sure that you're on the right path and also less feature-based iterative development. Because you could have gone live with the blog before you added it to the search index if you wanted to. I just gave you a structure. So that's what it looks like. And that's how you can help. And within all that work, that it goes into that 30% of the primary value stream. So all those tasks and that effort, you have your Scrum team and you're like, nope, they only have 30% allocated to do your blog. And that's why it takes maybe five sprints to do it. All right, but at the end, the stakeholders are engaged and informed. The business owners have their blog and they're happy. The business owners for the SEO like the supporting system, they're happy. The content is great. The blog is to SEO spec and they have analytics with it. The business owners of search, they're happy that the feature has a search component. The product owner is happy because everyone is happy and the feature is built. And you know what? Maybe as they were working on views, they had to patch it. And that developer got to patch views and also contribute back to Drupal.org. Everybody feels good in the end. So you have a very happy developer and happy customer. And so this prioritization can scale and everyone can use it. So this does apply to all sizes of business. So you can do this for yourself and you have a lot of ideas in so much time, right? So you can give your own level of priority. Small businesses with limited resources can apply this model. And also large businesses with so many stakeholders and stakeholders of equal prioritization. If you align what your overall value system is, that can help set priority on the lower micro, like the other departments. And this also applies to multiple teams. You can use this concept not only to technology or Drupal, but your business teams, your content team, your marketing team. And it applies to multiple verticals. So who works in education here? Okay, cool. How about government? And business? Yeah, lots of business here. Okay, and your family? Who has family? Everybody. Who has yourself? That's me. Or then family. So the big thing is this was incredibly focused from business process improvement and business process management and also classic project and program management. These are all very, very standard concepts. A lot of people, sometimes in education will say that will never work with an education. Because we just are different. The business is different, the people are different. And it's not different. There are some differences, but really, like, the enterprise has a lot of the similarities as a system. Same with government. There are some additional challenges in both. One person had asked, hey, like, I'm an edgy when they just don't value the work that we do. But it's not the value of the work that you're doing. It's the value of the outcome to the overall business or the organization or the school or the department. It's not about us as developers. It's about what we contribute, the royal we, the big we, to business. And who saw the Dries note? Okay, that's good. So who saw that he took a survey? Yeah, did people take the survey? Who saw that we had 75%, I think, allocation for like front-end and content improvements, content editor improvements, yeah? Who saw that there was like, hey, we need to keep the lights on and improve them? Yeah? Guess what? He totally did what I'm showing you today, right? And you're like, wow, okay, he is influencing change over a large group of people by showing value with data to and with market data competitor analysis with data from the rest of the team and also customer data. So we aligned all those things to then enable different people to do work and understand and he prioritized them. He created balance based on value. He's organizing initiative teams. So it's fantastic, like we worked, I had the opportunity to work with the Drupal 8 multilingual initiative. They're incredibly organized and it executed a lot of change along priorities for multiple people and it works and it works in the Drupal community. Also the Drupal 8 release process, the new one has frequent releases which helps both the customer and the developers so everybody is happy. It's all about that stakeholder is happy. They're actually using iterative development using experimental modules. Who's played with Drupal 8 here? Yeah, who's seen those experimental modules? Yeah, you're like, what's that? I want to touch it. What's going to happen? And what's going to happen? It means there's iterative development. You get it in people's hands. They're testing it. There's faster satisfaction for everybody and it drives we all like to build things and we like to use things and it's really increasing satisfaction across the board. So first of all I would say if you didn't see it, watch the Drees note. But Gabor and Webchik watch the potential in Drupal 8x and how to realize it because they are applying these principles exactly to the Drupal 8 release process and it's a beautiful execution. And it's hard because the Drupal community is very passionate but your communities and the business are also passionate. Government education, business your family, everybody your team. So take a look at it and it's very clear and concise and it's tactical. So the big takeaways is be master of the log right? You have to be master of the log. Be a leader and supporter of the extended team. You know everybody in this room is probably passionate about the position that they can impact change, a positive change to not just the team around them but their clients. And please place tie value of the work performed to business. Tie the prioritization to the work performed. Communicate it with your team. And what we do is classify the work by type that's in your main value stream like you know those leaders generation. Is it support? Is it cart? Is it selling? It will be different for your business or your education support or your government support. And you want to qualify the value commitment by the percent allocation of work. And as I talk to different people in the past, the biggest questions come down to, well how do you do it in Jira? What tools do you use? And that's a big question. And that's like eight talks. But what the big takeaway for that is let's talk about it. I'd like to do more topics about that because understanding how to communicate value and is hard. I try to get the most industry standard simplifications here for you guys to use as a tool to apply to your system. You will use different metadata and taxonomy to categorize your work and to organize it in different clumps. So people can have visibility and make informed decisions about prioritization and that your developers will feel squashed by the log. Do you guys have any questions? Can you please walk up to the microphone? Or I can shout it out if you shout it out. Hi. Any thoughts on estimation? Do you have any time next? Are you sure we're on that? Yeah, it's an art. It's different for every team and developer. And like what does your 30% mean? And so I'm going to ask you for some clarification on that. Which level of estimation? Is it the story itself? Or is it taking a big thing and breaking it down? Right. So it's answering the business stakeholders is how long will it take? Now that's a good question and it depends on the complexity of the ask. What we often do is say you've asked us for a very complex thing it's going to take time to estimate. So we estimate the time of discovery and that initial discovery. Maybe that initial discovery is discovery of discovery. Because they're like, yeah, I would like to implement an e-commerce system. And that ask is huge. Right? And that requires a program manager and multiple projects in parallel and impact a system. But if they're going to ask for like a bug to capture metadata that is something that you're like, oh, I can estimate that very well with my development team. If it's something that needs requirements flushed out with the business then it's like it's going to take time and then you do that. But what we do is also we have these things called spikes where it says spike define overall like who knows the term WBS? A few. Breakdown structure. It's the dependency tree of big chunks of tasks or deliverables to get from start to finish with an overall effort. So you can say make the spike to do that. And what that does is it gives them some time that says in a finite period of time I can get you more answers about how long this is going to take. But what happens is you're really up front with your expectation settings with the business. They're actually pretty happy about that because it allows iterative feedback conversations within the sprint structure on planning and estimation. Yeah. So the question was when you're constrained by fixed time events, how do you do it? Do you and one of the options they had was do some scope and feature control. And if we go back to that optimization structure you have to do the must haves. That's your primary value chain. That's your primary value creation. So you have to identify what in that deliverable, that's a timely deliverable needs to get done first. And you also have to identify within that effort you have to keep the lights on or we have to upgrade the module to give you that feature that you're asking to communicate with the team. We're going to do this big project initiative but it's actually improving so many channels. So what you end up doing is instead of having this big project that's just under primary value creation it becomes a program that takes a little bit of effort from each one of your reporting and metrics and the infrastructure team and then also your supporting systems like your SEO team. So, yeah. So I'm going to reiterate what was said so it's the everybody's number one issue so every to ask is a priority one and it's funny because we were working on a project and it was hilarious we had so many priority ones then we were like is that a 1.5? And it was the subtlest thing to say yeah it's still one and I understand that it's still a one but is it a 1.5? I think we still use 1.5s. P1 plus sometimes. Yeah and the end result is if you can't deliver to everybody everybody is unhappy and this is why you give ownership of a certain percentage of their bucket of prioritization. So the reporting and feedback business owner they have this much allocated to them they can choose whatever priority order they want and if they have business obligations that must align to something else that's also deploying that's their initiative and that's their responsibility. The primary value creation system that drives a lot of things the other kind of supporting system sometimes follow those big initiatives but it's the collaboration of all of those different business owners or process owners that need to happen and the work is allocated over those different percentages of work so that makes sense. Basically everybody has different a cup that they can drink from some cups are bigger than others and so you can drink your drink at your own pace and that is your cup. Now that's why we said the business percentage can change because maybe the business thinks a reporting project is much more important than something else so you can swing it for a couple of sprints but as long as you have that open conversation of like oh that's taking away from this other work because we have a finite number of time people and resources then it should be better because it's all about having that open upfront communication and expectation setting with the business owners. But then sometimes people are squeaky wheels and they'll not be happy with anything but you can do your best with data and prioritization. Oh that's actually kind of sailing the ship if you will and dealing with rapid changes of priority as you ramp up and ramp down the team some people can context switch pretty quickly if you can't. There were a lot of developers in the room so a lot of people know that once you're deep down into something you have to take a step back and go oh I was totally in that module and I was and to be halfway through it or right at the edge and have the business like change priority it's hard to do and it has a huge impact on productivity should I say is that what we're oh yeah absolutely so a lot of times what we do with the team is we have a pretty sex scrum team but as the work increases if the budget increases you can increase your team but there is overhead in adding people to the team because sometimes if you're in those crazy complex environments wow you have to get started like getting the development environment but for some of these crazy environments just takes time and education and not only that it takes time from the other people on the team because you have to come in and help so it's a huge impact to ramp up and ramp the teams down to the business and that kind of you can estimate that a little bit in your overhead but we also are clear with the clients that if we're going to add more people to the team we have to scope that in with the project so we have we have a story called get new developer setup or get new business person trained because a they understand that that time takes time and often they would say oh this stuff doesn't need to be in a sprint but then it ties back to the estimation questions somebody had but how do you how do you know that your sprint team can actually execute everything that's committed and do the weird side asks that they're asking you that's not tracked and so we were pretty adamant about no no no everything is to ask everything goes in the sprint so then we can track time to it and provide value and it's been fairly successful so otherwise it gets stuck in email and it's like ah thanks Ryan players that are competing for resources within the team we've found some success in requiring a single point of contact who is our decision maker so anybody in their team has to filter to that person and that person can be like oh I don't care about that and that allows you to say okay this one is really a P1 and this one is really not because to each person on that team their initiative is the most important and so if you have like five people from a team working directly with you you're going to find that five people will have a P1 so if you can negotiate with them that like this person is the person who says on your team what is what right so that's clarification so clarifying ownership is a huge deal and you know also clarifying ownership in your development team and skills assessment and skills realization often people have very complex projects and going well there's only two people that can do that but you've asked them for three other P1s over here it's not like our team can't do it it's just going to take forever to ramp up the other pieces so you have to communicate you have asked the super specialists to do these other things which one's more super special right also in the business having that one business owner one business contact is key so perhaps delegating out your developer contact to work directly with that business contact will help decrease kind of that weird overhead but it is challenging when multiple people are saying no no no the blog is this and the blog is that and they're all saying it separately and they all feel very important and maybe they are all differently important seriously like one's the SEO person and one is the reporting person and one is the infrastructure person they are all equally important right because that value chain that whole big stack of complex boxes they're all important in their own way and within their own perception so it's just how do you balance that as the hard part so it's 1141 however I don't know when the session ends but I think it huh? 145 oh okay so anyway you look have more questions yeah go ahead yeah let me talk to that you said thank you for the presentation and it's how often do you hear a product owner doing this and I didn't say much about me or where I came from so I'm a really I'm a really angry sysad man at heart um and that's where I started and then people in the business were making funny decisions and asking us to implement stupid crazy things and I was like how do I influence change and then I started on the project management and into product management and so it's been a long time for the triple kind of community to really start embracing this but I'm really happy that this is the first year that triple con has had a whole project management track and it's really refreshing and I have all the silly certifications and letters and training I say silly I'm in trouble because I have to list this as my professional development unit because I'm presenting this for my PMI PMP so sorry PMI but seriously like the Drupal community sometimes a lot of communities balk at the getting knowledge and education and they balk at certifications but those that are coming from a classic enterprise background they require those things so I'm going to wrap up a little bit with that and respecting that a little bit more it comes with the experience and everything and the whole the whole thing with me is I always like to build cool things and make sure everybody's happy and so that's evolved into kind of helping the product owner as much as possible I think and it uses technical skill and all the knowledge that I've gotten so it's a lot of common sense so I don't know but thank you and I'm so glad and yes there have been buffs but I think a product owner buff would be interesting any other questions, thoughts oh yeah so the team over there will go damn it you hijacked my dam scrum meeting I am the worst rule breaker because I like to break the rules and break them when they make sense so you should follow best practices and having a daily stand up sometimes we don't have sprint retrospectives if the team is like barreling through but we have a really open communication about what's not working immediately right now sprint planning is always necessary to align with the business and product owner it's necessary for the team to hear that it's not well planned and the homework is not done for the sprint planning development team over here how often if the business is not ready do you just like start coding and doing something else while I figure it out with the business so we've got nods and stuff and scrum master how much does that make you crazy because it's not following the scrum process he's making so and so sometimes I have to help do course correction for the client because the client oscillates a lot in a stand up but we make sure that the stand up is done so we have stand ups that are a little bit longer but we have a pretty big team we extend out to the business owners to come in and they actually come in and we do that for course correction so the frequent meetings are extremely important because that's why scrum works instead of waterfall because you have to show up and be awake ish sometimes people aren't but it really helps decrease the roadblocks and manage things early so the response was the team is distributed and we have to have that human check together or else it gets like echoey so the question was what internal collaboration tools we have a lot of people that are in various flavors of Linux and Macs and Windows and everything and they travel and their internet connection is interesting we actually as a team ended up on using Skype a lot now there's all sorts of cool things like Slack and that integrate that are cool they are cool but because Slack was slacky before when we started it's just our culture that we have Skype groups that are just open and what happens is if something happens and we need to share it with the team we just chat it in there because we have a people that are traveling, they get it on their phone it's the most I guess broad reaching easy communication app on all devices so but that is aligned with using like Jira and Confluence from Atlassian Suite we also use Zoho products for our internal site so it depends which client if we host the information for the client or if the client is paying for like the big enterprise Jira then we'll use their systems so yeah and I think that's time thank you guys so much it's been awesome to see you so I'll post the slides up in a little bit I just have to put them on a PDF they'll be on the session page thank you