 All right, so I think the time is 11 o'clock now, so we're going to begin. Today, as you know, we're going to talk a bit about going from a classic waterfall approach to an agile approach to web development. And we're going to focus especially on estimation. My name is Cecil Wittger. I'm senior project manager at ADAPT. And I'm responsible for project management and our overall processes. Yeah, my name is Mikael Bohansen. I am a strategic client manager at ADAPT. I started at ADAPT four or five months ago and it's basically in charge of implementing these agile processes at ADAPT. Okay, so on the agenda today, I'm going to tell you a bit about who ADAPT is. We're going to tell you a bit about why we decided to go agile. Then we're going to focus on estimation. And finally, we're going to tell you a bit about the results that we've reached so far. Who is ADAPT? ADAPT is a digital agency that unites business understandings, design and technology. We've been in the business for quite some time. We've created some results for leading international brands since 1998. We have experience with launching over 2,000 digital solutions. We have over 80 passionate employees. And as an ADAPT client, you're not just another project, you're actually a part of our team. We're an international company. We have offices in Copenhagen, in Kaunas, Vilnius, and here in Barcelona, and one in Boston. All right, to tell you a bit about what we've been through. Over the last three years, we've tripled our company size and tripled our average project size. We've gone from only developing on our own Perl platform to developing on a global platform, Drupal. And we've been working with agile for over a year, but we've intensified the process during the last four to six months. When we started out doing Drupal projects, we only did smaller projects with well-known functionality, modules that we've used before and knew really well. So, yeah, we thought we knew it all. So we worked with fixed budgets and fixed scope. We had a classic waterfall approach. Our projects lasted typically three to six months. And we started out by specifying all of the functionality that we were going to do. Then we designed how it was going to look. We started implementing it. Then we did our integrations. And then we started testing. And our clients started testing. And our clients and we started creating a lot of new tasks when testing. And since it was quite a long time since the original tasks were specified, it was often difficult for us to determine whether these new tasks were actually a bug for an original task or if it was a change request. And our waterfall approach didn't really support changes in the estimates unless it was an out-of-scope task, a change request. So we had challenges expanding our budgets for all of these new tasks created in test. And we didn't really have any tools for prioritizing our scope since our scope was fixed to a fixed budget. And we actually already developed all of the functionality at this point. So we couldn't really leave anything out and prioritizing differently. So our budgets didn't last. And we actually ended up losing money on 50% of all our projects, which is not good business. And besides that, our projects grew larger and more complex. We started doing more complex integrations using a lot of new modules that we hadn't used before and we needed lots of custom code to achieve our project goals. So we needed to redefine and specify our tasks during our development phase instead of in the beginning before we started development. And since our project grew, we needed to add more resources to the projects as well. One or two developers were no longer enough if we should meet the project deadlines. And since we added more developers to the project, they didn't all have the same knowledge or work in the same pace. So to sum up, keeping our original estimates was quite difficult when the task kept being redefined. And keeping a fixed budget and a fixed scope is also very difficult when you keep redefining your tasks and expanding them. Also staying within an estimate one developer has given can be difficult for new developers added to the project. So we had troubles staying within our estimates. So that's why we decided to go agile. So we started up really slowly by implementing concepts such as sprints and a project backlog and we started using a tool called Gira, as some of you might know. And we actually saw that these changes that we did improved our work but we didn't really have one person that was responsible for actually facilitating this process. So every time we had questions on how do we do this and why is this going wrong, we didn't really have one person to go to. It was just the person that saw the problem that maybe needed to go try to find a solution. So implementing these tools didn't really fix it all. We saw that we were having trouble with overflowing sprints, meaning then that when we ended a sprint a lot of the tasks weren't finished so they were needed to move to the next sprint. And this resulting in our project scope growing during the process. And we still faced challenges in keeping our estimates and we actually didn't quite knew why our estimates were keeping. So we lacked an overview of what went wrong. So we decided that we needed more focus and dedication if we were going to succeed in going agile. So we went all in. And that's where Miguel came into the picture. Thank you. Today I'd like to stand here and talk a bit about first of all what is agile because this is a beginner session. We'd like to get the basics into place and then I'd like to talk a bit about estimation. But first of all, why agile and what is agile? Some of you might be familiar with the agile manifesto. The funny thing about working agile is that when you talk to developers especially developers who have been in the business for many years they will tell you that's just what we always did. So back in 2001 there was a group who sat down and created what they called the agile manifesto. And actually it's just a basic one page about what do we mean by working agile. And they set up these four basic rules that you should follow. The first of the rules is individuals and interactions or processes and tools. That meaning that to be innovative it's done by bringing people together and let them talk, let them share ideas. Don't set up a lot of complex processes and tools that kills the innovation. But the funny thing about these rules are that I have seen a lot of times where people says this means that we shouldn't have any processes or tools at all. Especially developers have this idea that tools and processes are bad and in some way they're right but not quite there. So I'll be coming back to this subject later on. The next rule set up by the manifesto is working software over comprehensive documentation. And again here it's funny how developers kind of read this as we need no documentation. Of course we need documentation but when we create documentation we need to keep in mind that we shouldn't do anything that won't give us any value. So we should only do the documentation that we can prove will give us some kind of value. And of course that's always a good discussion to how we're the developer. The third rule is customer collaboration over contract negotiation. What is very important here is that we need to keep our customer, our clients very close to our process and make them understand why are we doing this as we're doing it. And of course we need a contract but basically for the process in the perfect world we should sign the contract and never look at it again. Because it's about the communication with the customer and again also we're here. The last rule which I personally think is one of the most important things about this is responding to change over following a plan. Actually the keynote this morning was right down my alley on the first couple of slides because it said yeah we tried to plan anything and he had this quote saying yeah you have a plan until you get a hit in the face and that's the same we experienced in our case. So it's very important that we need to be able to respond to these changes that will happen in the context we're working on. All here is working on IT platforms and we know these platforms are moving very rapidly. So therefore we should be able to adopt all these changes that will come from the world around us. So how do we do that? First of all we need to go away from the old waterfall model as Cecil just told us. We had this problem with the waterfall model that in the end of this process we get the feedback very late from the customer to find out this is not really what we needed. But basically we probably have spent most of our budget building what we thought that they need and then we got a problem. So in the iterative model instead we go through the same steps basically but we do them all over again, all over again and again and again because when we work on a project we accumulate knowledge and it is this knowledge that we need to use when we do this all over again. So instead of doing these steps in like maybe three to six months we need to do it down in like two to four weeks instead. Because then we get the specification, the design, implementing, integration, test, installation and then we can actually produce, deliver some software that is working out here and then we could do this all over again. And then we can put the software into market and why is that a good idea? It is a good idea because if we do it on an old basis we know we want to end up out here and then we start to build this corner and that and work out there, that's not what we want to do because there's a good chance that we have a misconception out here. So instead of that we need to build something that will solve the basic needs of our customers. We're working with a concept called the minimal viable product. It is the least product that your customer can put onto market and get working and why is that a good idea? Because when customers start to interact with the software that we produce then we get the feedback. And very often we'll find out that what we thought that the customer needs is not what the customer needs and especially what we thought was the most important is not anymore. And you can say maybe if we go like this and we start making this skateboard and this and the bicycle, we might end up here and find out this actually solved all that we need, all the customer needs. We had this idea that the customer needed to be for in the car and they would go driving out on a rainy day and then when we started out the customers never came back to us and argued that I need to bring more people with me or it's raining all the time and then there's no reason to build the last step. So this is very important that we accumulate this knowledge. Basically we are working with the method at ADAPT called STRUM. I think most of you should be familiar at least with the name of it. I'd like to go through some of the basic terms that I'm going to use a lot today just to be sure that we're on the same page. So first of all, instead of these old school specifications we work with a concept called user stories. You might have heard of it before. It's quite simple. We just define our task on the basic form as a type of user. I want some goal, so that reason. And what we use that for is that we can see what it is that we want to achieve and this is written on a form that even our customers, non-technical customers can understand what it is that we're trying to build. Then we take these user stories and put them into a backlog. A backlog is simply a prioritized list of tasks that we need to get solved. And then we have the sprint. The sprint is a time box. We are working with sprint of two weeks and it's kind of the same going back to the iterative model I just showed you that we time box and say we commit ourselves to do these user stories within this time box. And that's called the sprint. Then we have two rows that we'll talk about today. One of them is the product owner. The product owner is the guy who owns the product. And the product here is the backlog because that contains all the user stories that we want to build. And this is responsibility to maintain that the user stories is doable and that they're always prioritized. On the other end we have the scrum master. The scrum master is typically a guy from the team, might be a technical guy, and his responsible is the sprint. So he and the team, working with the product owner, finds out what can we say that we'll do for the next two weeks. And then we say, okay, we say this is our task. We need to do this as a team. So scrum master owns the sprint, and the product owner owns the backup. There's, of course, a lot more to this, but I could stand and talk about that for several hours, and I don't want to bore you too much. Please let me know if there's any questions about this. Good. You mean you don't dare to ask. Then what is it that we're trying to do in ADAPT? We want it to have this vision, and we quite fast find out that we have this dream. We want to reach the agile nirvana and reach the promised 60 to 150% better effectiveness. I think everyone who have had anything to do with agile methods have heard some of these promised better effectiveness that you always hear in these conferences and stuff like that. And then what happened? Then we got the same problem I've seen so many times, that you got the management who said, that's what I want. So go fix. That's fine. And then what tends to do, then, okay, we know we want to work agile. Then we look into the toolbox with agile tools. Find a tool and then go look for a problem that we can fix with that tool. That's a problem. So what should we do instead of that? Of course, it's good to have the vision. We always need a basic vision. But after that, we have to break it down. Break it down to missions. What can we achieve? How and why are we going to reach our vision? And we did that task in ADAPT. And first, we find out that one of our biggest problems, as Cecil just told us, is that we had a lot of projects that were kind of spinning out of control. And of course, this is very expensive both for us and for the customers. We want to avoid that. It makes good sense. Another thing we want to do is empower the developers. We like to move the power and the organization out in the end of the organization because then we can take faster decisions out there and empower our developers and our employees and thereby make faster and better decisions because I very often see that people go to management. They've been working maybe full week on a problem and then they go to management and ask for a solution for this problem. And of course, the best person to know anything about the solution for the problem they have but spend a week working on it. And the last thing that we took in here is that we like to increase the quality of our deliveries because quality and deliveries is the same as customer satisfaction and that's always good business. And I can stand here and list a lot of stuff today but today we like to just focus on the first one about avoiding projects spinning out of control. So the next thing we did is that we need some goals. We need something that we can mission say when this is done we should have finished this mission. So when are we there? The first thing that we can take out from what Cecil told us earlier is that we need to have an earlier awareness of problems in the projects that we can't finish the project in time at least not with the scope given right now. The next thing that we like to do is that we like to know why do we spend more time on these tasks because we spend a lot of time going back and trying to find out what went wrong in this project. Then we need to remove overflow from old to new sprints. We started working with sprints but saw this overflow so the sprint was just a time box that we really didn't use because it was like when two weeks went past we just looked at our board and said okay we have a lot of tasks that we didn't finish we'll just move it to the next sprint or even just kept extending the sprint. So we like to get rid of that and at last and not least we like to keep the estimate within a target of plus minus 10%. That would be great. So now we got the objectives. What is it that we want? Then we can see how we will implement some solutions for this. And of course we can say that Agile is the headline of the solutions but here now we have the problems. Now we can go to the tool box and see what kind of tools do we need to fix these problems. So first we like to get this better tracking of issue types because we have this problem that everything was just allocated on these basic tasks. Everything was like registered on the user stories. So try to split out the issue types and user stories, administrative tasks, technical tasks so we can see where are we spending our time. Next thing is we implemented Daily Scrum. Daily Scrum is just a basic meeting that you have every morning with the team. It shouldn't take more than 15 minutes. This is important. And you just gather the team, basically it's good just to stand up and everyone give a report of what did I do yesterday, what do I like to do today and what kind of problem do I face. And then we take the talk there and basically we can keep it within even with a team like eight members we can keep that down to like 15, 20 minutes. Then we find out that we like to get some clearly defined roles because we didn't really have these roles and if you don't have roles but you have a project manager everything seems to end up with the project manager and that's not very good especially because the project manager is not necessarily the guy in the project that knows most about it. So we needed to define these basic roles that we're working with. Next we needed to define our processes and now this is where the developers come and say hey we don't need processes because you got the manifesto. Yeah but we really didn't have anything. So we needed just to get the basics right and it might be a good idea to just start implementing the basic processes maybe a bit more strict than actually you would do when you are working at job but then later on you can start removing the processes that you don't like. And then we got the concept of story points planning program and tools for forecast and going a bit fast here because I like to actually go back to those but when we have the strategy of how we want to achieve our goals our objectives we need an iterative action plan and the work iterative is quite important because management tends to go to the teams and say hey you need to work to be agile when we work and be able to adapt to changes we need to do that as well in management that's very important. Make some small changes see if it's working if it's not change it listen to your developers when they get back to you and say this doesn't make any sense for me you have two options remove the problem or tell the developer why this makes sense that's the only two ways to do it so maybe we got the action plan we're ready to go we know who will do what when so now I like to take some time to talk about these three areas because we have one headline that we can put to that and that is estimation and again the talk this morning was right down my alley about what is the problem about estimation and to plan your work because estimation tends to be when you talk with management about estimation and you give an estimate it's like that's the truth there's no way that's going to change but actually I like to not call it estimation but call it fortune telling because then people would be a bit more sceptic and that's good so why is this a problem first I like to talk about the relationship between time, risk and knowledge because there's a model I really like and everyone should know it's called the cone model the cone model looks at uncertainty and how that works over time it's quite basically because over time we get knowledge and therefore our uncertainty kind of narrows and that's good of course so in the start of the project of course we don't have that much knowledge of what we're doing right now so we're kind of lost to be honest then sometimes when we start working on this and we get a better idea of what we're actually doing and they end up with a project we know everything about it and it's way easier for us to tell how long will this be because we kind of did it we just need to do the math but when you tell this to management that we would really like to do estimation out here this is kind of the reaction I usually get because they can't use that for anything because we need a budget upfront but the problem here is that we don't have that much information out here and we tend even though we know that we tend to try to do all the task breakdown estimation and everything out here and that's the problem what we should do instead is that we should accept that we don't have that information and therefore know what you don't know is kind of the key here and people will often go back and say how can I know something that I don't that doesn't make any sense and that's right of course but you can know that you don't know it and when you know that you don't know it then you can accept that you don't know it and when you have accepted that you don't know it you can make it work for you so this lack of knowledge is not necessarily a problem because there's this thing about knowledge that it devaluates over time quite fast so what we tend to do in the classic waterfall model is that we try to do a lot of research up front in the project and then we start working on it and find out that all the time we spend on this research it's not really what we want because you're starting to produce a product that the customer can check and see that this is not working for me so I like to talk now a bit about how can you do this wrong because we have these projects coming in and all of them have a total budget I guess you are in the same place as us and what we do is that we knew that there was something that we didn't know so we just allocated some time as a buffer some money as a buffer and then we just took our user storage broke them down to soft task and then fill up the scope what we had for the scope and then all is fine and we start working what then happens then we have a user story that expanded because there's something we didn't know okay that's good we can get working on user story 2 and 3 and started to run in the same problems we can see the buffer is now kind of used we have a little bit left so we kind of concerned but it's okay as long as the rest of the user stories will be within the estimate then everything is fine but what is the chance that it will but that was kind of the way we worked with it and actually what we should learn here we probably should panic here when we still don't know what will happen here so how to handle that we use the concept of story points let's take this scenario again why this is a problem we have the management going to the developer saying how long will it take to do this some kind of task that we need to do and the developer says I have no idea my best guess is like 150 to 250 hours from what I know right now and for some reason management tend to hear that this is manageable within 150 hours as you develop it down here laughing, fantastic but actually this is not the biggest problem that we have with this way to do things the big problem here is that we're actually not doing this right if we try to be a bit more scientific I'm not a biologist I'll say at first but if you look at how the brain works we take an isolated item and present that to a person and we like that person to describe this object then we get this problem that the brain actually tries to set up thousands of items it can compare to to try to describe this and that's very hard on the way we think so instead of that we can put in another object to compare this with and even though again I'm not a biologist I can quite fast say that I'm sure that this organism is way more complex than this organism and I can tell this is an animal this is from a plant and already there we can actually say a lot about it not having that much knowledge about the specific of this but we know what is you can say the difference between these two objects and that's actually what story points can do for you you can tell you about what is the difference in complexity compared between two objects to user stories and this is a way easier way for the brain to compare objects and actually all kind of studies show that this will give more valid estimations of course there's also a downside to this it can be very hard to make your customers your clients to understand the concepts of story points and especially this that a story point is not a static thing it's only telling us about this object compared to this object what is the relationship and we can do that within a project maybe within a team but the most common mistake people do here is starting to compare story points across teams across projects because it might not be the same value that we are working with so a small exercise here I'd like to do I'd like to ask you first how many of you have played with Lego when you were a kid fantastic so now we've collected a bunch of experts in Lego so the next thing should be quite easy I'd just like to ask you this model I have here how long will it take to assemble it I know you don't have the manual any guesses 10 hours that was fast I need you next time I built a Lego figure not that many you like to give they're good 100 to 400 that one guess and I'm getting a bit concerned here because you are hopefully all in IT business and no one asked what should this one do what can it do maybe we don't know but if now I say okay I don't like to know how many hours it will take but I put this model in instead and now I ask another question I'd like to ask you which one of these will take the longest the one to the left or the one to the right anyone who wants to come with a guess on that who said right hopefully it will be the one here to the left that we come quite fast see that this is quite complex and my next question is if you can only say on a scale is this twice the time four times eight times 16 or 32 times then you actually might have an idea on where on the scale we are that's all we want to know because we don't have more information right now but now we have some idea on how these two how complex they are compared to each other and how do we do this in practice in everyday basics we start using the concept of planning poker which is a great guessing game planning poker is quite simple we get the teams together everyone gets a thick of cards like this and you can see it's raising quite rapidly and that's good then you get the team into a room either with the scrum master or the product owner and they take one user story and describe the user story quite fast and the team are not allowed they are allowed to ask simple basic questions but they are not allowed to start discussing how do we solve this user story instead of that they take that big of card and pick one card and then they can show the card to us and thereby we can see how complex did they think that this user story are and sometimes there will be quite a big difference between how complex your developers think that this user story are so instead of starting a discussion now now we just take the guy with the highest card and ask him why do you think this task is that complex and he got the chance to say oh we need to make a lot of customization create our own modules from scratch and stuff like that and then we go to the guy with the smallest value and say he can then tell us yeah but there's some good modules out there and that might actually solve like 95% of all we need to do and then they can have a short discussion about this probably a guy with an 8 sitting in the middle say hey yeah you might be right I've been working with that module and quite sure we can make this modification and then we'll be reaching like 100% ok wonderful then everyone picks up a new card do the same as we did just moments ago and we should be at least nearly on the same page of course there can be a situation where we're not but here we can say ok that's an 8 and always be a bit more pessimistic if you're in doubt if you have a big span still in numbers here there might be a good reason for that it might be because we don't have the knowledge that we need to do this and there can be two reasons for that one thing can be that the user story that we got is not good enough then the product owner have to go back and revisit this user story and that's ok the developer should never allow a bad user story to get through here it's their responsibility to make sure that they understand this and they can vouch for for this estimate the other thing that actually even though this is very highly skilled developers there is some technical questions that they can't answer because they have not worked with this before and then we can make a time box for them you'll usually call this a spike it's like you're setting off like let's say three hours and say it's ok we can allocate three hours for someone to go researching on this and then we should be able to do it and then take the user story off next time you do this planning focus session and the guy who spend the three hours can then tell the rest of the team this is what I think and this is also one thing of course it gives great estimates but another good thing about the planning focus session is that you also get this as a forum to share knowledge between your developers so don't think that you can do this just one or two guys do it with the team so I like to talk a bit about after this because now we know how we find out our user stories now we need to find out how do we make these work for us in everyday basic and I need to say that this example is extremely simplified because basically when we work on projects in ADAPT we take in like 50 to 100 user stories for a project but if I put 100 user stories up here I think I'll lose you on the way even with the small amount of user stories I might and please don't feel free to ask questions on the way but basically what we have is we have this backlog of user stories and we know how many story points we have for each user story so we know the complexity compared between the user stories but we don't know how far can we get we can't take the story points right now and turn it into ours so what we like to do is that we take the first user stories take some of the highly prioritized user stories and the user stories that you feel most comfortable about take something that you have done before something that looks like at least something you have done before and then we break them down to subtask and put an estimate on them in ours and then we can do some basic math we can take the total hours here in this example we have like 89 hours then we can take the total of our story points and do some basic math and say how many hours do we spend per story point this is also called our velocity this tells us how fast are we moving forward for every time we spend 100 hours how many user stories can we expect to do so basically we get this I cannot simplify we don't do that many projects in this size but just for the example and manager come in and say okay I have only 160 hours that's alright now we have to find out how far can we get for 160 hours we have the velocity so now we can just do the simple math and find out that 160 hours with the current velocity is like 70 story points wait now we can see how far we'll get we'll actually get to solve up to user story 9 and after that we can't do it within this scope so there's only two ways to fix this if the customer comes to tell us we really need this there's two things we can do we can remove a user story here or we can expand the budget that's what we can do so then we start working on the project and what then happens then again we run into the same problems as we did before we still have some tasks that we couldn't foresee that this would be more complex of course we should also run into tasks that is less complex but just for the example here we take the more pessimistic view of it so let's say that some tasks user stories is getting more complex than we have hoped then what to do this is very important keep your story points static don't change the story points the only time you want to change the story point if you change the user story a lot because this still represents what we thought was the complexity of this user story compared to the other user stories so what we really want to do is that we need to skip this one and do it all over again so now we actually worked on it so now we have some more knowledge and we can take that knowledge into the game so we can again say okay we have 63 hours we only ended like 18 story points now our velocity is 3.5 oh and therefore we have now a problem that we won't get as much done as we hoped to but it's better to know it now than to know it when we have done the whole backlog so now we just expand the rest of the user stories with this factor and we can see okay this is going to be a problem now we can only do the first 6 user stories but we can take this discussion with the client and customer up front and find out a solution for this we are working out from time and material basics they just pay power so we need to guide the customer here and help them and show them how much we'll do and we can always tell them this is how it would look like right now then we start working on some more user stories we can be lucky that some of them are less complex than we thought and then we do this again but we need always to keep tracking this and now back to the headline time management is so important here and why that? Just in time management means that we should only look at what we need to work with right now because in the other model you saw we tend to do that we look at all our user stories and then we broke all the user stories down to soft tasks at the time where we have the least knowledge about this project and that's a problem because every time we found out that something changes there might be some external APIs that didn't do as we expected or anything like that that we can expect to hit the rest of our user stories if we already broke all these user stories down to soft tasks then we have a lot of user stories that we have to revisit in this model we only have to revisit what we already work with what we already broke down so now we don't have to spend that much time revisiting stuff does this make any sense to you? Fantastic some is nodding and some is just falling asleep this is the basic model that we work from now and now just get this again Alright to tell you a bit about the results that we've reached so far well we see that it works but it's work in progress as I told you in the beginning we haven't been doing this dedicated for such a long time yet so we still have a lot of work to do but we can see that one of our main challenges keeping our fixed budget we kind of solved when we continuously revisit our velocity to redefine and prioritize the scope then we can keep the fixed budget that's a good thing also one of our big challenges was the estimation and that has improved a lot in accuracy when we're estimating our tasks at Sprint Startup we bring in our learnings from earlier in the project which again makes the estimates far more accurate also when we're doing the planning poker as a team instead of just one person estimating then we both support knowledge sharing but also we get the team to commit to the project again that's a good thing that results in more precise estimates but there's always a but implementing agile methods is hard work and it depends dedication and investment also we experience that it's often difficult to explain to the customer how prioritizing functionality can be a good thing they really just want it all at the same time and sometimes when telling them that we want to build what gives the most value to your end customer it's kind of hard to accept that you're not getting all of what you thought you were going to get we also experience that some of our customers simply aren't ready for agile they think it's too risky not knowing exactly what you're going to get and also on our small projects that might only be like 2 or 3 sprints the whole scrum thing can be difficult to implement or at least using your velocity because you don't get to know so much about the project when you're only doing 2 or 3 sprints yes one slide to rule them all I have seen is the most important when you start and I think these agile methods is no to organizations are the same you need to customize these methods to the context that you're working in I've seen so many companies reading a lot of books sending all their employees to be certified scrum masters and they don't have anyone to kind of take the responsibility for this to happen on an everyday basis so it's so important that if you want to go back and implement some of these methods always keep in mind what is my context of this what can I use and again go for the iterative action plan try to implement some of it see how it works adjust it, adjust it, adjust it all the time you're never done doing this not even Google are done doing this they also adjust these methods along the way so I think we're quite there fantastic first of all any questions about these slides I think you need to go to the mic actually because it's been recorded hi can you hear me better so a simple question you're talking about different user stories in my experience they're quite interdependent so if you deliver this user story one you've already built some of the functionality for user story two and how do you estimate based on that interdependence that's a very good question it's a question I hear a lot to make this short first of all it's good practice to break down your user stories in smallest bits of course there will be some tasks that you can say this is associated with all my user stories what we did is that there will be some technical tasks first of all that you can say setting up test platforms and stuff like that is just we need that done we made that as a specific issue type so we just took it away from the user stories then you can say you can also have some like a module that would fix multiple user stories then go for the user stories user story with the highest value the highest business value and allocate the time, the basic time for implementing the module on that just remember it because then when you look at your backlog again and compare your business value with the estimation and think oh this is going to take so long time I'd rather have these four but then you have the relationship between them and screw up things but it's very important to keep it down to multiple user stories because when you do that even though you're implementing a module that can fix multiple user stories then you can still allocate and saying it's not very often that you see one module fixing everything for all user stories it might fix like 90% of the user stories that it associated with but you still need these last 10% and you still need to keep the user stories for that and say okay for the first user story I'll implement the module and I fix it so it will solve this user story and I know I have some other user stories that are highly prioritized and you can end up with a project all our projects have this fixed budget and at the end of the day we'll find out that there might be some other small tasks that we actually rather have than fixing this module doing the rest of the user stories so keep the user stories because then you can still prioritize even though it's a small fix to a module that will fix this user story another small fix that is more valuable to you does that make sense? good there was other questions no one wants to go to them the guy in the blue shirt there so how would you sell customer this idea that if they pay x amount of money they may get 3 stories or 5 or 10 or 1 I know it's hard but do you have any pointers how would you the way to sell this to the customer is to explain this process explain to them why is the agile method better than the old waterfall model and the way I usually explain this to customers is that there are some surveys that show that when you do the waterfall process you tend to build way more than you actually need and when you have this time of material contract with the client the guy is paying for this and one survey showed that 60% of all you built end up in a category called never used or rarely used and we don't want to build that for the customer the customer don't need that it's a hard job basically no doubt about that but what we're doing in the doubt is that we keep these processes very close to the sales team and make sure that our sales team understand why do we do this what is the value in this for the customer but it is a hard job but take your time to present these methods to the customer and make them understand why it is a good idea yep, there's one guy standing at the mic hi the poker game seems really intriguing and I'm wondering how you transition to getting a lot of developers and strategic minds in the sales process to the estimation process because it seems like a lot of people's time something that you may or may not sell at the end of the day so it seems like you're playing poker you're gambling with people's billable time that's a very good point what we can do about that is that in the start of a project instead of working with these highly specified user stories in the beginning because we can't spend a lot of time working on a contract that will never finish then rather work with with epics which is like a very large user story that just explains big chunks of the functionality in the end system and then do the planning poker for that with a couple of lead developers and maybe the client manager and then take it from there but again make the client understand that this is not a contract with a fixed scope we don't want to do that kind of contracts so yeah that's basically what I recommend doing and then of course at ADAP we're focusing on making this analysis phase for the customer because it's very often that a customer comes to us with an idea of what they want and when we put it through our UX department we'll find out that's not what your customers need okay yeah, next Hi, so when you're in the sales phase with a customer and you are able to sell this kind of agile process to him but he still says that I need some kind of budget I still need some kind of ballpark figure how much does this project cost how do you approach that first of all I'd like to turn it upside down and remind the customer this is not about how much will it cost because it's not an interesting discussion to have with the customer that a product can recreate within the budget that you have and then you can say we expect that we can do this that's our best guess right now and then we start working on the project making these analysis and stuff like that and what we actually like to do is that we like to just sell this analysis for the customer and spend like maybe two three hundred hours just finding out what is the right solution for you and we've done that then we had a lot of user stories actually the customer is able to go to another IT house to get this built if they find out this is not we were working on Drupal but they might find out that this is not the right platform for the product they now know that they should build and that way we would like to do that first of all let's separately and then find out should we build it on Drupal very often you can say from our point of perspective this can be a bit risky of course but now we have accumulated all this knowledge about the project so it's not that easy to go to another development house anyway with that I'll answer the question my question is around how you organize yourself over like with scrums over your whole organization how do you manage several projects with scrum at the same time I don't know if you have maintenance projects if you have ongoing client relationships do you deal with these things yeah how much time do I have maybe you want to answer that question well we have an organization that's client team based meaning that we have actually four client teams with a group of developers a UXer a project manager maybe also a project coordinator so we have our clients attached to one team and they stay in this team even for maintenance afterwards and within the client team we also have a scrum master and a product owner but do you have then per team several clients because after some time you will have then a bunch of clients yes we have very different size clients actually so we have one team that is almost only working on one client and then we have other teams working on several clients and yeah it is a challenge doing lots of clients in the same team but we make it work alright my question is about user stories and tasks so when do user stories turn into tasks and how do you estimate the points without knowing all of the tasks first do developers estimate the tasks or how do you break it down to tasks what we do first of all is the developers who will break this down to tasks that is very important because it is the developer who is going to solve this tasks and they need to have this ownership of it the way we do the breakdown is that that's another reason to do the planning poker session with the whole team because then you have this knowledge sharing about the whole project and thereby you can assign maybe two developers working together some part of the project break that down to sub tasks and some other can do it another way but basically this is why it's so important that your backlog is always prioritized because you start breaking down the user stories from the top of the backlog first again this just in time management is so important because else we spend way too much time just trying to break down tasks that when we finish the sprint we'll find out okay we're never going to use this anyway we just wasted time did it answer the question? when you're planning sprints how do you mitigate the risk so for example you've broken down your user stories you've got them all prioritized and you now have a list of tasks and some of them are longer than others some of them are more complex than others do you approach it with most complex tasks first do you give the client a quick bang for their buck and do some simple tasks first how do you balance that it's a hard job basically again going back to the backlog we need to sort the backlog from what give us the most value and that should be the main key for what you build first of course there can be if you can say the budget is so big that we know there's a bunch of stuff that we will build we can't launch without these then of course it's a good idea to build the most complex user stories first but as soon as you say the word complex user story you should revisit that user story and see if you could break it down to several less complex user stories that's quite important because then you can prioritize them again and it's very rarely that you have a complex task that can't be broken down to several user stories a lot of persons trying to tell you that it can't be done but it can the first is about requirements who actually the requirements and are those in your user stories are they deep and detailed or the developer kind of you know works off of that that's another thing I could talk about basically we use these user stories in a user story we have this model saying that as a user I like to be able to do something for some reason and then the product owner is the owner of the user story from here but the product owner we see that as a role that can be shared by multiple people and especially the client we need to have our client very close to us and they have to take part in this role as the product owner so they will be a part of creating these user stories of course we'll have one person very often in our organization the product manager who is like in charge of making sure this is done and the quality of the user stories is alright but we do it with the customer and very often with our UX team we'll do it in the analysis phase that we do our front in the project another thing it might be out of scope of here but testing how do you integrate the testing or estimates for testing that's the reason that we introduce these new processes because that was a big problem for us the quality for the first review from the customers was too bad to be honest that we have these basic errors that the client should never see because they just lose their comfort in the project and they don't believe that we are the right house today if we quick showing them bad stuff so we changed the way that a user story lives through the project and make it necessary for the user story to go through QA for example both by the developer who did we have the review the developer test on the test platform then it goes to QA then the customer sees it and first when the customer accept it it's done for the sprint and that should all happen within the sprint and then again very important that you keep your user stories very small and so do you try to resolve bugs within that sprint or do they overflow yeah always resolve the bugs within the sprint that's very important one of the problems that we had before was when we started work on our bug then we couldn't remember what user story was this related to and then it's hard for us to say is this actually a bug or is this a change in the scope and for the user stories we have these acceptance criteria that we put in which is like things that we can say check this is actually done by the system now and it's way easier if you get in the bug we can see is this related to an acceptance criteria within the user story great thank you I think we can take the last question then we're running out of time we practice agile we do everything that you're talking about and we still struggle with definition of done I'm interested that's a classic is that the session over now you've got to go the waterfall process almost gives you an exact pass or fail at the end you either did what you said and agile gives you we did 80% of what we set out to do and some extra stuff or 90% and so on what the client wants and if you manage clients like the satisfaction for the client is all about a bit of a wow factor they feel good about everything they got delivered so what's your definition of done first of all I need to give you a short answer here because we're running out of time to keep it short we have made our own definition of done I haven't brought it here and I'm quite sure it's not making any sense to bring it here because again no two organizations are the same but the first thing I would say is that it's good to have this definition of done created do it in collaboration with the organization and make this definition of done and only have one that's actually the most important because I heard the term done done so many times and I like to break down every time of the guy that tells me that there's only one done and it needs to be done within the sprint the only thing that we can we can put outside the sprint is that we merge it to the production that should be all that is left on a user story when it's done for the sprint do what that's for the project actually for the whole process for the way we work we have the same definition of done for all our projects but yeah it's a good point you might want to do it per project good I think we've done yep just to before we leave if you have any further questions or comments we have a booth downstairs it's called ADAPT and me and Miegel will be standing there during lunch and until 2 o'clock so please stop by I'd like to show you some more slides about this definition of done if you like to I have a full slide show of it