 Okay, I've been practicing my Irish. Are there any Irish in? No one. Oh, just one. Then just for you. I'm glad so many of you showed up during the lunch break. That's great. I'm standing here. I may not have all the answers, but I'm willing to give it a go. And at least I'm able to share my experiences with you. So my talk is called The Seven Hurdles to Reach Scrum Group on Nirvana, Y7. I'm not quite sure, but it sounded like a nice number to start with. Of course, there are a lot of hurdles when you try to embed Scrum within your company, but I try to figure out what the biggest seven issues are. So who am I and why am I standing here? This is some facts about me. I've been working in open source for quite some time now. When I was about 14, my brother gave me a computer with Linux on it. So that's where my open source hippie heart opened up. And I'm still an open source hippie. And I will always be that, I guess. I call myself a semi ex-drupalista now, because I've made for my work my profession all the way around. I've made for my work my hobby again, I'm sorry. Because I'm not into Drupal anymore professionally. Maybe I will be once again sometime, maybe. But for now I'm working at VakonSelect as a Scrum Master, full time Scrum Master. And we do that net. Sorry. I'm loving Skid since DrupalCon London. He's in the audience. We're having our five year anniversary today at this DrupalCon. So that's very great. And thank you, thank you. And my open source hippie heart opened up for the agile part of it about four years ago. So I'm an Agilista and a Drupalista. I'm really curious what kind of audience I'm having. Are there any Scrum Masters? Please raise your hand. Okay. A couple of them. Product owners. Three. Okay. More. Project managers. More. Okay. Handball players. No team handball players. Guys, you really should. It's awesome. Okay. Here's a little thing, what I'm going to be talking about. First off, to truly understand the hurdles, I would like to give you some more in depth view and give you an insight on how I think the Scrum Master role is to be defined. That's why I will start with a little in depth on the specific Scrum Master role itself. And I think this is because a lot of people know the theory behind it. But what it takes to be a true good Scrum Master is to be defined, I guess, to get to the hurdles. Then I will talk some more about the seven hurdles. Using Scrum within digital agencies. I know that's broader than just Drupal agencies because I think this talk is also for other shops, so it's digital agencies. And after that we will have an answer round. Okay. Let me take you into Scrum Mastery a little bit. To start, I just picked up my Scrum Guide and check what Scrum Mastery is all about. This is what Scrum is according to the Scrum Guide. It's really easy to understand. Everybody understands Scrum, the way it works with all the circles and the adapts and inspects and the sprints and the stand-ups. Everybody gets that, right? That's not that hard. But really, to master Scrum, that's really difficult. So, I agree with a lot of experts out there that you should have a dedicated Scrum Master in your team. It's not a part-time job. Was that me? Probably nobody else is wearing a mic. If you say Scrum Master is a full-time job, what do you do all day? That's a question I get a lot. I don't know if you ever have asked the question. If you have asked the question, is Scrum Master a full-time job, then you're in the right place because I'm going to show you why it is. I don't think a team lead developer can be a Scrum Master at the same time. And I know that happens a lot, but I'm on stage so I can shout out whatever I like. I think you need a dedicated Scrum Master. Same goes for product owner Scrum Master role combined. That's a conflict of interest that will never work. Or any other company member doing the Scrum Master role next to their normal role. I don't think that's a good idea. For Scrum Master, I think we're kind of like the Drupal Association of the company. This is the goal of the Drupal Association. The Drupal Association is dedicated to fostering and supporting the Drupal Software Project, the community, and its growth. So I stroke out a couple of lines there. And I think it's very close to the Scrum Master role within the company. The goal of the Scrum Master is dedicated to fostering and supporting the Scrum process, the community, and its growth. I will take you back to the Scrum Guide again to show you what the Scrum Master does. Let's go back to the Scrum Guide. Responsible for ensuring Scrum is understood. That's basically the part everybody understands, right? The Scrum Master explains Scrum to everybody within the team. Make sure the three-year-interpractices are done. The daily stand-up is there. And that all the Scrum rules are being followed. But next to that, you're a servant leader. Sometimes I see job applications and it says the Scrum Master leads the team. No, the Scrum Master doesn't lead the team. The Scrum Master servant leads the team. But next to the team itself, you're also responsible for the organization around it. The thing is, the job title A-Jow Coach isn't in the Scrum Guide. The Scrum Master is the A-Jow Coach, basically. So it's not just making sure the retrospectives are being held, all the events are being held. But you also have to garden the organization and help them change. My next slide will give you an overview of types of Scrum Masters you can encounter within organizations. I stole that from Angel Medelila from his presentation, How to Develop a Great Scrum Master. And I think it gives a great overview of the types of Scrum you have. The Scrum Dude, that's typically the guy or girl who was a developer and some management thought, OK, we're going to do Scrum now. You're a developer and you're basically the technical team lead. So I think you also should be Scrum Master. Which is just fine. It works. So he or she schedules meetings and does all the things that has to be done. But you will never really grow the team. Because he only facilitates everything. The second one is a more dangerous one, the Scrum Mom. And I'll explain why it is. Because as a Scrum Mom, I've been there, done that, really. I've been Scrum Momming around all the time. Really protective of the team. Sending away a product owner, sending away stakeholders. No, you've got nothing to see here. Go away. This is my team and I protect them. So I will remove all the impediments for you. Give me your impediments and I will take them away. The idea of a Scrum Master is essentially that you make yourself obsolete. The team should be self-steering. If you ever encounter a Scrum Mom or recognize yourself in it, please remember that that is not the way to create a self-steering team. Because the moment you do something for your team, which they can do perfectly well themselves, you own it. So every time you do something, you own it. So you become Scrum Mom and the developers are happily developing and never will make the next step to becoming a self-steering team and get rid of their own impediments and not just yelling at you, please solve that for me, Mom, right? So the true Scrum Master facilitates, grows, helps, encourages and is a gardener. That's basically what a true Scrum Master does. I'm not quite there yet. I'll admit, I'm still somewhere stuck between here and that's okay, right? Everybody needs to learn. Trying to. The almighty Scrum Master checklist. Just one more giveaway about the Scrum Master roll. It has checkboxes and it has a Google Doc version in which you can fill out the checkboxes. So that helps, right? This is sort of a to-do list. And basically what you are doing for the rest of the organization. That won't work. I'll just skip it. It's in the presentation. It tells more about how you can help your product owner because they need a lot of love and nurturing too, of course, to help them get their backlog right, to help them get their stakeholder management right, but also achieve the final goal in having an HL enterprise. So on to the seven hurdles. Hurtle number one. Scrum and the customer. Who have you have a customer that really, truly understands Scrum? One, two, three, four ish, three and a half. My point exactly. It's really hard when you are in an organization and you are full aware of everything that Scrum can offer you and offer your team that you have to make money and you have to have customers for that and they have to understand the way you work. It's very, very hard. So they will ask for functional designs. They will ask for technical design. They will ask how much will it cost me? What will I get? And when will it be ready? So I got some tips and tricks which I found helpful to get over this hurdle. Start with the offer. So don't wait for the signing of the contract. Start with the offer. Make sure you get really clear the way you work, the way you want to work, the way the things you expect from your customer, the things they can expect from you. So please do so in the offering phase already so they know what they can expect. Get together. The way I've seen Scrum working best is when the team is at the customers or the other way around. Someone of the product owner of the customer is at the team. Because you have to work closely together, right? The agile manifesto says, conversation over contracts. Please keep communicating. So the best way to keep communicating is to get close to each other. So bond with your customer and get together. Work together. Mind the product owner. I'm going to make a stance now which is sometimes not really well received. I think a customer should never deliver the product owner. It happens a lot, but the product owner role is really hard. It's not something to think lightly about. It can be a full-time job depending on the size of the project. And it's a profession. And when customers start a web project or an application or anything like that, probably you will end up with someone from the communication department or some IT person who will have eight hours a week for you to fill their backlog and do stuff like that. Do the fill in the product owner role. From my point of view, that's not the best way to go. Have your product owner on your side with your team and let the client be the stakeholder. So you can have a dedicated product owner at the customer side, but I think the best projects are made with product owners who know their job and know their profession. And that takes a while to learn. And you can do that in a couple of months' projects. You cannot learn it that well. So a lot of people disagree with me on this, but that's okay. I can talk with you later if you would like more in-depth information about that. Educate, educate, educate. Start with workshops. Explain what you're doing. Explain what the events you are doing. Show them your backlog. Show them how you work. Show them your board because I'm definitely a fan of physical boards and not JIRA or, yeah, it can help, but keep on educating. And not only from the start, but keep on checking as a Scrum Master are my stakeholders still in with the game? Do they still understand what we're working on? Then we're up to hurdle number two, Scrum and Drupal Development. Scrum talks about team members. You have a couple of roles. Product owner, Scrum Master and team members. But of course, in every Drupal company, you have front-end developers, back-end developers. There's maybe in your team, but also junior, media, senior. And how do you make sure that everyone in the team is on the same page and can help each other with user stories? But sometimes there's some serialism in the user story, so the back-end has to go first before the front-end can do its work. It's kind of hard when you try to do Scrum. To try and get your team to be a team, be a gardener. The way I use it or I do this is anyone familiar with Daniel Pink? The puzzle of motivation? Not everybody? Okay, I'm going to explain something about it. You should go and watch his 18-minute TED talk about motivation of knowledge workers. That's really great. He says, of course, money is important, but it can never be a motivator. Motivational employees, they are motivated by three things. It's autonomy. I can decide what I am doing within the team. Second one is mastery. I have the skill set, I know everything I need to do my job the best way I can, and purpose. Everyone who's working at a website or application wants to do that for a greater good, and that's the way to keep people motivated. I do that individually with my team members. I'm a Scrum Master of three development teams, so I have talks with them. Do you need some more knowledge? Is the purpose clear for you? You can do it also on a team level. Is the team autonomous enough? Has the team all the mastery that you need to build the best web projects you can? And is the purpose obvious? And even, I'm about to make it one step further to see level, to get it all in line so that everyone in the company knows what the purpose is. Daniel Pink, what's that guy that he's so cool. So that's my way of being a gardener in my development teams. Do use the most powerful tool in the Scrum Guide. Anyone, whenever, try. It's an event. Thank you. Retrospectives. The only way to become better at what you do is to inspect and adapt. Keep on inspecting and adapting. The retrospective, please people, don't skip it ever. Don't. Because, thank you. Because that's the way to make your teams better. Because they stand still, look back, check what they're doing, and inspect what went wrong, and do it better next time. So you will get a better, faster, more happy team. Do use it, please. And for the Scrum Masters, I've seen a couple, have a Scrum Master toolbox for it. I'm really working very hard on it. I'm having three teams, and we're having two week sprints. So that makes up for 75 retrospectives a year. You will need a toolbox. There are great sides for it. Tasty cupcakes is a perfect side to find great ideas for good retrospectives. And try to mix and match them. There are different kinds of retrospectives. Sometimes you feel that there's a problem in the team with the communication. Find one that suits that problem. Sometimes it's technical depth. Sometimes it's a lot of bugs. Find a retrospective suited for each situation and each sprint. What I found out, the Scrum Master before me was actually a very great guy, so I'm not here to criticize him, but he used the same retrospective over and over again, and just people came with filled in post-its before the retrospective. Well, once they do that, change your retro. That's a great moment to change your retro. So create your Scrum Master toolbox. I work at the camping company, so I literally have a suitcase, which says Scrum back on it, and I use that as my Scrum toolbox. Scrum and the HR department. Now, this was for me personally a very fun situation. I was working as a product owner, but the role didn't really suit me, so I went looking for a job as a Scrum Master. So I uploaded my resume, and I got called by a lot of recruiters. If you ever consider a job change, try Scrum Master. There's a lot of work in it. Only the funny thing was that all the recruiters I talked to weren't looking for a Scrum Master. They were looking for a project manager. They were looking for sort of Scrum Master product owner, sales person account management, someone. I've had so much crazy calls of, yeah, it says Scrum here in the job description, so it must be a Scrum Master then. Please do educate your HR department. There was even one where I also had to test the software. I don't think so. Other people are better at that. To educate your HR department, get involved as a Scrum Master. You know best what you need in your team. I will get back to the Daniel Pink, the autonomy mastery, the mastery part of Daniel Pink. You know what's missing in your team, right? What kind of skill set and what kind of attitude you need. So get involved in the hiring process. Do that because HR people are not skilled Scrum people. Make clear what different functions are all about. Missing an S there, but you can read it anyways. And mind skills versus attitude. Because I've met some crazy, intelligent, very smart, ideologically fast developers who couldn't communicate at all. So, well, they could, but they weren't willing to. So that's an attitude thing. Skills can be learned. That's not a problem. You can teach anybody anything. That's at least what I believe. But attitudes you can change. You cannot change, I mean. So find the right person for the job and help your HR department with that. Four, I think this is the biggest hurdle of them all. I've never been to any Scrum events, Scrum meetings, Scrum, HL, Meetup thing where this wasn't a subject. But how do we do support? It's not in the Scrum Guide. But we deliver websites and we deliver applications. And we do have to do support. How? I'm not pretending I do have the sublime answer to this, but I do have some certain ways to try and fill it in and see what works out. Again, inspect and adapt. If it works for you, stick with it. If it doesn't work for you, try something else. There are a couple of the ways I've found to do so and try it. A burning issue backlog. Have a separate backlog for your support questions. And if they're due this print because they're absolutely blocking, have them on a separate backlog and have time boxes within the teams if you have more than one team. Say they have time boxes a day to work on the burning issue backlog. That is a way. I found that not to be ideal because you do have situations where the burning issue backlog is too big to fit into the time box and then you have to engage with your product owner again to see what goes out of the sprint and you will lose the momentum of the sprint and the cadence of the whole sprint process. So it is an option, but I'm not quite fine with it. This is the one I like best, but the problem is it's not always possible because of this... I'm sorry, I'll just finish this sentence. It's not always possible because the size of the company, of course. If you have two teams, you're not able to have an extra team for your support department. Sorry, you had a question? The time boxing team ensure that your burning issue backlog doesn't interfere with your sprint time. It's the whole point of the time boxing as I see it. True, but... Well, if Drupal Gadan comes along and your time box isn't big enough then it will interfere with your sprint anyways. Of course you try to time box it and try to keep it that way so that you can see in the future how much work you can do. But there's always... Everyone knows, I guess, that there's always burning issues coming along. For instance, if you do e-commerce and the payment thing isn't working, you have to fix it, right? So it can work, but it's not always the ideal option. A certain company now working in this way. Great. Well, that's good for you. Absolutely. Probably a good coach, right? He's an old colleague of mine. And he's a great programmer. I was talking about the dedicated team with Kanban and it works when you have enough body as a company to do that. I've seen that working at some big e-commerce companies in the Netherlands and that seems to be working just fine to fix the support problem. Currently, in my company, we are trying to work with chapters. So we have... Everybody knows the Spotify model? Maybe. You have the teams vertically and you can have chapters horizontally. So we have, in every team, we have a support engineer that are over the teams to get the support done. We're trying to let them figure that out themselves. So that's where I'm moving from the Scrum mom role to the Scrum master role. We just asked them to organize yourself and make it happen. And they're actually doing that right now. But it's fairly new. So I will let you know maybe next year how it worked out. And I've also seen the support engineer per sprint. You have one team member dedicated in your sprint who is only working on support issues of all the customers. The good thing about that is that the knowledge about all different projects is better spread within the team. You have to... Everyone within the team knows what projects there are and have technical knowledge of the site or the applications. I found that we do that. We have one person in the sprint that will do the UAT issues as soon as they come up. What we've done is we rotate that role amongst the team so that you're not the same person who doesn't do that every sprint. You have the knowledge spread around the team. So it's one of the things that works for us as well. Great. Thank you. I will repeat it because it's being recorded. A perfect addition from the audience is that the support engineer does rotate the role of the support engineer. Does rotate within the team. And it works for you. Great. Thank you. I think you're in stoop bubbles. There you go. Scrum and technical debt. It's always a hard one, right? Because... And this is also why I think the product owner should be within the agency. Because this is the hardest part to explain to a product owner what technical debt is and why it's important. Please be bold about technical debt. There cannot be one sprint coming through without solving technical debt if there is any. And everybody knows there's always technical debt. So please get rid of it and be bold about it. If you sense in the teams that they're only working on new features and never on solving problems, let the team explain to the product owner that they really need that. Educate your product owner about it. One thing I saw at another speech was figuring out the business value because technical debt does have business value. A lot of product owners says you will work on that for three days to solve a problem, but it has no value. What I've seen is business value can be on different quadrants. You can have business value for the team, business value for the customer, business value for the internal organization, business value for the customer of the customer, and you can make quadrants of it. And you can decide with the team and with the product owner to give out business value points to each quadrant. Business value isn't flat. It isn't just value for the end user, but it's also value for the team. If they can do their work three times faster, that's great value, right? So, figure out business value of your technical debt and use very much smart models for that to make the product owner understand. This is also a nice one, right? Last year in Barcelona, I talked about fixed-cope, fixed price. I don't know if anyone has seen this session, but scrum and project budgets, it's always a problem. A lot of management 2.0 is about Excel sheets and customers really want to know the costs and what they can expect and what will be delivered at what time. And basically, in the beginning of the project, or building the product, there is no problem at all because the customer still has budget, but once the budget is slinking and it's getting smaller, then the problem starts. To figure out, to get control of the budget of the different projects you are working on, keep the number of the projects low. I've worked at a company, sorry, where we did 14 projects in one sprint. That's not doable, and actually, he told me yesterday that they brought it down a lot, so that was a great tip for my presentation. Keep the number of projects low per sprint because ideally, and I know that's not always possible, have your project serialized instead of parallel. So try to do one project at a time, and I know that's Nirvana. But at least give it a try and keep the number of projects in one sprint very low. Let the customer pay per sprint, and not per hour. The biggest waste, I think, in IT is our registration. Thank you. Those are the developers, I guess. Of course, the customer has to know what to pay for, but I think if you can get them to pay per sprint or pay per half a sprint even, you will get a lot of frustration out of the way within your team, and they can do what they're good at. Plus, you don't have to be a sort of nasty person chasing everyone around. You should write your hours because that's the worst job in the world, right? Skip the hours. Please, bill per sprint. Just no more hour registration. That's my final goal on this, that's on my bucket list. Hour registration out of this world. Explain the rise of value for money. If you skip the hour registration and you have the billing per sprint or billing per half a sprint, you can explain that because you do your retrospectives, right, that your every sprint, the customer will get more value for money because your team is inspecting, getting better, delivering more each and every sprint. But the price stays the same. So they get more value for money each time. You do a sprint. And please don't mess with sprint lengths. Time tracking. Time tracking, yeah, I'm sorry. Is that your opinion thing? Or just Dutch? I'm sorry. Yeah, time tracking. Right. Drink length, please. I know. As you know, we and I think most group of shops have always have multiple projects, multiple customers per sprint. So the only way to make sure that the customer gets what he deserves is to do some sort of time tracking. Make sure you distribute the hours accordingly to the project. So how are you going to manage that without time tracking? Oh, I think it's best to do that based on velocity, I think. Not quite sure. Does anyone have a better answer than I have? Then you could say, okay, you're paying for a sprint per developer and not just... And then it's easier to manage. But one of the goals is actually to have all the developers work on every project so we can spread the knowledge. And don't have projects being dependent on just one developer. Of course, but they don't have to work on the same project all the time. They could be like this sprint, this developer works on that and next sprint, it will be that developer. I just got a signal because nothing of this will be recorded. So it's not to be rude, but if someone has more smart things to say, maybe you shouldn't use the microphone that's over there. Okay, let's do that. Okay. Well, I already stressed this out enough, I guess. Don't mess with your sprint length because otherwise everything up will... just won't work anymore. The last one, scrum versus scrum bot versus water scrum. Please always try for the real scrum because that is what truly makes people happy. That's what I believe. I've heard someone say, yeah, we do stand-ups and yeah, we do things with post-its on walls but if you really, truly want to grow with the whole company and with the whole team, try to use it as much and as good as possible as well as possible. Scrum will work for you if you manage to take the six hurdles and I know it's hard being there, done that. Once again, please have a dedicated scrum master who can help you with it and make sure you get one who goes to events to get more knowledge from other scrum masters. Read the scrum guide and check it. Check if you really are following the scrum guide rules because most of the time you think you are doing it the right way but keep on checking. Again, don't ever skip the retrospective. Don't, please don't and have your management believe in an agile enterprise. I'm going to end this slide with a little story about this man. This is my CEO. He's called Luke and he's truly an agile and scrum believer. That's why he hired me so I'm very glad I'm working there at the moment. Luke started that 30 years ago with the camping site near the Lake Garda in Italy and he started with a field and then he built some infrastructure on it and then he built some toilets on it some sanitary things and so he built a camping and then it just went bigger and people weren't able to stay at his camping anymore so he booked them to other campings and in 30 years time he grew to an e-commerce company now and we do bookings all over your specialized in glamping glamorous camping so that's a two-story tent with a Jacuzzi but ok that was his dream it's awesome, it really is awesome so it's a European company now and the first time he hired an agile coach and he said explain to me what should we do I want to become the best e-commerce company in the Netherlands what should I do so he explained the agile coach explained the whole scrum process to him and he said well that's just like building a campsite right so he truly in his heart and in his gut understands how agile works and that's why I love to work for this guy and I will end with a quote from him because I love it so much when people call me crazy I know I'm on the right track thank you ok I want to do this a little differently I called the sheet answers and all questions can you please just take a look around see how many people are here I can assure you there's so much more knowledge in this room than on stage so why would I take the questions so I got more strewpuffles for the best answers in the room is there anyone with a great tip, trick or hint on one of the seven hurdles just to pick up on the sizing and the time tracking from before scrum doesn't have anything to do with ours there's no way in scrum we use story points I know it's a fluid size but when I size a project we leave a tender and offer the customer gets let's say not three months or six months and so many resources 1500 story points what's that and then you have a discussion about how do you the customer prioritize your story points so you can come with all your stupid request or very brilliant request in the duration of your project but you will only have this fixed size of story points and that sort of tames and disciplines your customer as well and that really helps we never talk about ours you get this amount of resources how you want to internally in your agency move people around that's your headache the customer already knows the bill beforehand and if you come and 215 I will speak much more about this at another session thank you is there anyone who has a great tip about how to handle technical debt yes sure is there anyone who has a great tip about how to cope with technical debt you have an idea it's the waffles right just plan it in advance build it into your time if you know that you're going to have to manage technical debt what you're going to need to do just plan a sprint in between the sprints for technical debt I've done this on several projects it's been really helpful technical debt sprint solves that problem great sort of legacy sprint why have you ever had them they're great okay anyone else any more great tips on support how to handle support within sprints or any of the other hurdles more service level any other great tips guys I need to get rid of these any questions then yeah sure can you walk to the microphone please or someone handed to him or hi I'm developer so I don't know many I don't know a lot about these scrum things but my question is do you people do estimates and then look back at how close you were to the estimate of the development like if you say I estimate it will take eight hours to complete this and then do you time track and evaluate it we don't use hours at all with Instagram we use elephants and mice for instance I think this feature is an elephant and I think this feature is a mice or story points but to look back and see how well you've done you know in your heart as a developer how well you have done you know it I don't have to ask you that and we don't have to report anything about that the next time you will have a planning session you will know better whether it's an elephant or a giraffe or a mouse or two hundred or two thousand story points or t-shirt sizing that also tends to work yeah oh I forgot the mic again sorry for that but I think it's too well for Worthy almost out of time right quick question you mentioned product owners and how sometimes they are really stakeholders or should be are you identifying someone within the customers realm who is a good product owner versus this guy should be a stakeholder what's the red flags you always can find the one wrenchable neck if you say okay I'm going to stop this project now the first one at your desk is your product owner because that's the one who really cares who really feels it in his gut most of the time that's your stakeholder but again I think it's better to have the stakeholder at agency side how do you define oh that's up to the team they know instantly because you use stories are not written well the product backlog isn't tidy and working out yeah product owner will be known instantly within the team not really no someone in the back no one more question the question yeah I'm sorry the question was how do you do scrum with a small team with just three or four people I think that's really hard anyways because the scrum has a sweet spot is between seven and nine five and nine developers right I never worked with a small team like that so I'm not quite sure actually yes you can he's up for the true profit that's the only reason the only reason I'm standing just to answer that the strict answer would be you can't so there's no way of doing scrum with that small team yeah it's not gonna it's not gonna happen at all I would suggest that you go for can band or something that's much more malleable it doesn't have as many rules that's cool it's absolutely no problem to work with small teams and scrum and he will explain in his session soon but you will get a lot of overhead if that's what you're asking for but the process stays the same if you're one or you're ten I've been on a scrum team with 15 and it worked but it takes some getting used to there's a lot of overhead when you're two that's why you work with five to nine people because then the overhead is okay thank you I think we work in we have a scrum team of five people so it's not quite as small but what we do is we either look at velocity driven capacity or capacity based planning so what we do at the beginning of a sprint is you look at how many development days you have available we always do two week sprints so we plan for nine days you leave one day out for meetings and all the ceremonies and based on those nine days of development we plan the work based on that so it's really about and then before we actually commit to anything I always give them a mirror of what they've committed to so each individual team member is actually looking at okay I'm actually committing to X number of hours or X number of story points or whatever way you want to measure it before you ever press the big green button to start the sprint and I find that I think it is down to whether you go with a velocity driven capacity where you're measuring story points per sprint on a team basis or whether you're driving it through a capacity based model where you're looking at all the available resources you have for that sprint and how many development hours or story points you have and I think that works to the other guys point there like I think it doesn't matter whether your team is three people or ten people that if you do it it's all about the planning and that's the way I've worked it anyway and it seems to be working fine okay thank you hey couple of questions from a product owner perspective number one any good tips on how to keep the stakeholders aware of what's going on so that they don't feel that things are moving too fast or I wasn't involved or I didn't know that we're at this stage already you do have a square mast yes that helps yeah try to involve him or to educate it keeps on coming back to education to help them understand what you are doing with your teams I don't know are you working with some sort of rolling roadmap is it visible for your stakeholders what the teams are working on now and the following couple of sprints well this relates to a specific project that we did with a scrum model some time ago and I was kind of the lie eyes as a product owner towards our organization kind of telling what's going on and then we had an external scrum master but some of the team members from our side were kind of confused at some point that have we already decided these things because things were moving faster than people who are accustomed to kind of committee type of working they thought that things take longer so I just thought that where did I drop the ball of informing people how to involve them you were too fast that's actually great well the other question is actually I forgot the other question but I'll stick back and think about it that's no problem at all because we're running out of time anyway really quick on a really big project we had several departments all with a common goal so it was a lot of stakeholders like 20 and we had decision meetings so they were regular, they were set and they were right before sprint planning when you needed to make a bunch of decisions that were going to help prioritize we would have that decision meeting and it was always like some major things coming up where do you, what's your stake and that helped us a lot let them sell their business value why they think it's important that's actually a good tip because one thing I thought that I kind of missed was to highlight the decisions even more that we are now making decisions or we have made decisions but yeah the other question was about managing the internal pressure and expectations as a product owner any tips for that because there's that kind of thing happening how is your management the management of the company feeling about agile and scrum well it varies because they can help a lot with keeping calming down the stakeholders because they can say okay we're going to choose that way so stick with it next to that you're the product owner so you're the one responsible and you have to have the authority to say to them okay we're going that way or that way so is your mandate big enough within the stakeholders and if you have a problem there I think you should talk to where we're in charge Matrix organization for example might be difficult to have a mandate that kind of covers everything because you have dotted lines going everywhere so that might be a bit tricky environment to work in I don't have a solution for it but try to get your mandate in order and use escalation lines for it to get it because you're the one who's to blame at the end of the day right exactly yeah so try to get the mandate that's the best tip I can give you I think we have to wrap it up I'll be here because otherwise we're going to be kicked out of the room I guess just one question how many of you are in your self-organizing teams include design in that two weeks print I'm impressed for Europe just like one sentence concerning the hours versus story points in one of our clients what we do is we have story points that are only base two so we have tasks that are two story points four, eight, 16 32 and 64 and those roughly are converted to hours just but not it's not strict so it's like two story points is going to be a really easy task could be finished by one hour, two hours and 32 story points it's like two days the problem with that is people are going to still think in hours if you really want to do it just don't do that because I have a team and a sprint isn't a fixed couple of story points right and the idea is that because you get back to the depth and get better as a team that your velocity grows and that you can do more in the sprint but your hours are still the same so if you turn them back to hours again you will be stuck with the same problem and you will never make your team fly because I have a team which started a couple of months ago with 70 and now they're at 260 I don't know how many hours one story point is so an experienced developer could do like 10 story points job in one hour while a non-experience will do it in five hours that's what you're saying but it will level out in the team but don't match it back to hours please because you will lose the strength of the story point thank you thank you all and I have to make and join sprints presentation yeah