Userstories a practical intro

Editor's Notes

• #2: \n
• #3: User stories - what’s the first that falls into your mind when you hear the word?\n\nFor me it was fairy tales told by an user... \n\nAnd then I realized that it was requirements... but small? \n\n
• #4: Some people says: “Requirements as one sentence”\n\nThat’s nice - short documents is better than long ones right?\n\nBut you could write; “The application should work”\nAnd that’s a bit unclear now isn’t it?\n\n
• #5: My name is Marcus Hammarberg\n
• #6: I work at Avega Group as a contractor doing agile / lean coaching with focus on system development\n\n
• #7: I have 1 wife\n\n
• #8: 2 hobbies\n\n
• #9: and 3 kids\n\n
• #10: I’ve been a programmer ...\n\n\n
• #11: since 1998, mainly on the Microsoft stack\n\n
• #12: During the last 8 years I’ve taken more and more interest in how you can work effectively together with system development\n\n\n
• #13: using agile methods such as Scrum or Kanban\n
• #14: Michael Cohn is the name of the man who has written the reference work around user stories - user stories applied. It’s still a very good read and current. \n\nThis presentation is based on that book but I’ve added my own experiences from using techniques such as BDD and Specification By example\n\n
• #15: The book describes an user story as:\na promise of a conversation we will have\nSomething we will take more about\n\n\n\n
• #16: And further:\nA written descriptions that is used for planning and estimation\n\nA little text that we can use to plan and estimate how much work we have ahead of us\n\n
• #17: Through conversations we find out the details around the user story\n
• #18: One way to document those conversations is as tests or acceptance criteria\n\nIf you are to write test for a function you HAVE to know what it’s all about. In great detail. \n\nSo in effect we’re making sure that we understand the story in the same way. \n\n\n
• #19: One important aspect of an user story is that it’s describing something that gives an end user some value from the feature that the story describes. \n\nIt’s not a description on HOW to build the system. \n\nBut rather WHAT the user wants.\n\n\n
• #20: One important aspect of an user story is that it’s describing something that gives an end user some value from the feature that the story describes. \n\nIt’s not a description on HOW to build the system. \n\nBut rather WHAT the user wants.\n\n\n
• #21: You could go so far as to say that an user story is not a requirement. \n\nOften you document the business rules and requirements in other ways.\n\nUser stories is just a way to split up a requirement in smaller parts to be handled in iterative incremental delivery\n\n
• #22: But why is user stories so well spread and loved in the agile community?\nWhy do we want to write small requirements?\n\n
• #23: It’s a common thing that developers (me included) thinks that we get the requirements too late, but in most cases they are actually written to early.\n\n
• #24: Requirements have best-before-date. They rot if the lie around for too long, right?\n\nIf you write a requirment today and leave it, what are the odds that you can just pick it up and code away on it a year from now?\n\nSlim, huh? Things change\n\n
• #25: So by writing small, parts of requirements we give ourselves possiblities to decided later. To change course, take another road later. \n\nWe don’t have to write all the details up front - we can defer the specification of those until we really need them. \n\nJust imagine us writing a big specification with all the details and then find that it was down-prioritized against something else. Waste - in it’s purest form. \n
• #26: Ok so an user story should be short. \n\nBut what is enough. When have I written enough?\n\n
• #27: An initial good tips is to write it on a small paper, like a stickie. \nWith an ordinary pen. \n\nThat limits the physical space that you have to your disposal. \n\nBut sadly it still gives you the possiblity to write: “The system should work!”\n\n
• #28: Ett annat bra tips är att börja prata om acceptanskriterier. \n\nDå skapar man sig en förväntan om hur “stor” user storyn är. \n\nMan skriver ner ett par saker som måste fungera för att anse att man är klar. \n\nHey - då börjar vi redan tänka på hur det ska testas också vilket alltid är bra att få med tidigt. Jag återkommer till detta\n
• #29: To help with that there is a template for user story that I recommend:\n\nAs a [role]\nI want [feature]\nSo that [benefit]\n\nThis help you to focus and still write short\n\nThere’s a part in this that I love:\n“So that [benefit]”\nI never read that in a use case. Even 40-pages ones :)\n\nThis is the reason for us to do this story. If there isn’t a reason for it (or a bad one) then we probably could use our time better somewhere else.\n\n
• #30: In fact some people thinks that it’s so important that they put the reason of the story at the top of the template. \n\nThis is why we do this, right?\n\n
• #31: Here’s an example\n
• #32: And here another\n
• #33: Ok.. Ok... But WAT?! \nWAT is it that will be so great by using user stories then?\n\n
• #34: First and foremost it will “force” us to communicate.\n\nWhen we talk face-to-face we communicate so much more information than we do in written words. \n\nThink about why we created smileys for example - because irony and jokes is easily mis-interpretted\n\nBesides that we create a dynamic and learning from each other, we feel as being part of the process. \n\n\n
• #35: An User story is easy to understand. \n\nEven a non-techie understands them.\nEven a techie understands them. \nEven our customers might understand, for all I know.\n\nThat said - you should require some domain knowledge. Every concept need not to be explained from the ground up on every user story. \n\n
• #36: An User story is small. \n\nTo get to the right size we need to “break” bigger requirements into these smaller slices of that requirements. \n\nAnd when we do that activity we learn about the details of the requirement. \n\nSo - what’s the right size... \nWell not too big, not to small... Right sized - quite simply\n\n
• #37: Using user stories gives us small items that is perfectly suitable for iterative development where a small increment of a complete function is delivered\n\nAn user story underlines the fact that there is an user benefitting from the function, so we want each increment to add to that. \n\n
• #38: In the same manner you want to deliver a whole function, although not a complete function. A small slice of the system if you want. \n\nLike this: [CLICK]\n\nAnd not like this: [CLICK]\n\nOr this: [CLICK]\n\n
• #39: In the same manner you want to deliver a whole function, although not a complete function. A small slice of the system if you want. \n\nLike this: [CLICK]\n\nAnd not like this: [CLICK]\n\nOr this: [CLICK]\n\n
• #40: In the same manner you want to deliver a whole function, although not a complete function. A small slice of the system if you want. \n\nLike this: [CLICK]\n\nAnd not like this: [CLICK]\n\nOr this: [CLICK]\n\n
• #41: In the same manner you want to deliver a whole function, although not a complete function. A small slice of the system if you want. \n\nLike this: [CLICK]\n\nAnd not like this: [CLICK]\n\nOr this: [CLICK]\n\n
• #42: In the same manner you want to deliver a whole function, although not a complete function. A small slice of the system if you want. \n\nLike this: [CLICK]\n\nAnd not like this: [CLICK]\n\nOr this: [CLICK]\n\n
• #43: In the same manner you want to deliver a whole function, although not a complete function. A small slice of the system if you want. \n\nLike this: [CLICK]\n\nAnd not like this: [CLICK]\n\nOr this: [CLICK]\n\n
• #44: Earlier we learned that an user story is a “promise of a conversation we will have”. It’s not the complete requirement. \n\nWe will talk it out. Later. And then we will get all the details needed for this user story. \n\nThis is well-aligned with how agile methods looks on requirements. Do it Just-in-Time instead of creating a stock of specifications, just-in-case, that just run the risk of getting old. \n\n
• #45: Check out rolling wave planning and you see what I mean. \n\nStuff that is far from being developed can be big rocks that we haven’t started to break down yet. It’s ok - we don’t need to know more about it right now. \n\nBut as you get closer to manufacturing (the shore) you’ll need to clear out the details enough to understand what you are building. \n\n
• #46: No - they don’t. \nNeither do you. \nNobody does - to get there you’ll need to cooperate. And communication. \n\n
• #47: Ok - stop the bullshit!\nHow do I write a great story?\n\n\n
• #48: Firstly; the work is not just cracking you fingers and write the stories out. \n\nRather is more about breaking a big feature down to a more appropriate size. A size that can be handled by our team in 2 weeks for example.\n\nSo if you have a big story like “Customer want to see all their engagement with us” you need to break it down to, for example:\n“As a bank customer I want to see my banking accounts on the overview in order to get a quick look on my economical state”\n“As a insurance customer I want to see my insurances on the overview in order to get a great overview of my insurance situation”\n“...”\n“...”\n\n
• #49: There’s a wellknown acronym that tells us to INVEST in our user stories\n\nIndependent - this means that each story should be independent from others, as far as possible. Since we will use them to prioritize and estimate we want to be able to change the order of them, without having chains of stories coming along with it. \n\nNegotiable - this is not the requirements, just a reminder that we will talk it more later. The exact content will be discussed later. \n\nValuable - each story should give an user (or customer) value. The users doesn’t care if we use MVC or WebForms. That’s not content suitable for a story. Describe it in terms of value for our customers.\n\nEstimable - the story must be written so that you can estimate it’s size. You need to understand it enough for example. If it’s too big you need to break it down. Story points can be useful here - more on that later. \n\nSmall - an user story should be in the “right” size. Small but not too small. What’s the value for an user to edit the first name? Prefer small but not too small. \n\nTestable - how do we know when we are done? You need to be able to answer the question: “When are you done?”Write the acceptance criteria on the flip side of the sticky for example.\n\n
• #50: There’s a wellknown acronym that tells us to INVEST in our user stories\n\nIndependent - this means that each story should be independent from others, as far as possible. Since we will use them to prioritize and estimate we want to be able to change the order of them, without having chains of stories coming along with it. \n\nNegotiable - this is not the requirements, just a reminder that we will talk it more later. The exact content will be discussed later. \n\nValuable - each story should give an user (or customer) value. The users doesn’t care if we use MVC or WebForms. That’s not content suitable for a story. Describe it in terms of value for our customers.\n\nEstimable - the story must be written so that you can estimate it’s size. You need to understand it enough for example. If it’s too big you need to break it down. Story points can be useful here - more on that later. \n\nSmall - an user story should be in the “right” size. Small but not too small. What’s the value for an user to edit the first name? Prefer small but not too small. \n\nTestable - how do we know when we are done? You need to be able to answer the question: “When are you done?”Write the acceptance criteria on the flip side of the sticky for example.\n\n
• #51: There’s a wellknown acronym that tells us to INVEST in our user stories\n\nIndependent - this means that each story should be independent from others, as far as possible. Since we will use them to prioritize and estimate we want to be able to change the order of them, without having chains of stories coming along with it. \n\nNegotiable - this is not the requirements, just a reminder that we will talk it more later. The exact content will be discussed later. \n\nValuable - each story should give an user (or customer) value. The users doesn’t care if we use MVC or WebForms. That’s not content suitable for a story. Describe it in terms of value for our customers.\n\nEstimable - the story must be written so that you can estimate it’s size. You need to understand it enough for example. If it’s too big you need to break it down. Story points can be useful here - more on that later. \n\nSmall - an user story should be in the “right” size. Small but not too small. What’s the value for an user to edit the first name? Prefer small but not too small. \n\nTestable - how do we know when we are done? You need to be able to answer the question: “When are you done?”Write the acceptance criteria on the flip side of the sticky for example.\n\n
• #52: There’s a wellknown acronym that tells us to INVEST in our user stories\n\nIndependent - this means that each story should be independent from others, as far as possible. Since we will use them to prioritize and estimate we want to be able to change the order of them, without having chains of stories coming along with it. \n\nNegotiable - this is not the requirements, just a reminder that we will talk it more later. The exact content will be discussed later. \n\nValuable - each story should give an user (or customer) value. The users doesn’t care if we use MVC or WebForms. That’s not content suitable for a story. Describe it in terms of value for our customers.\n\nEstimable - the story must be written so that you can estimate it’s size. You need to understand it enough for example. If it’s too big you need to break it down. Story points can be useful here - more on that later. \n\nSmall - an user story should be in the “right” size. Small but not too small. What’s the value for an user to edit the first name? Prefer small but not too small. \n\nTestable - how do we know when we are done? You need to be able to answer the question: “When are you done?”Write the acceptance criteria on the flip side of the sticky for example.\n\n
• #53: There’s a wellknown acronym that tells us to INVEST in our user stories\n\nIndependent - this means that each story should be independent from others, as far as possible. Since we will use them to prioritize and estimate we want to be able to change the order of them, without having chains of stories coming along with it. \n\nNegotiable - this is not the requirements, just a reminder that we will talk it more later. The exact content will be discussed later. \n\nValuable - each story should give an user (or customer) value. The users doesn’t care if we use MVC or WebForms. That’s not content suitable for a story. Describe it in terms of value for our customers.\n\nEstimable - the story must be written so that you can estimate it’s size. You need to understand it enough for example. If it’s too big you need to break it down. Story points can be useful here - more on that later. \n\nSmall - an user story should be in the “right” size. Small but not too small. What’s the value for an user to edit the first name? Prefer small but not too small. \n\nTestable - how do we know when we are done? You need to be able to answer the question: “When are you done?”Write the acceptance criteria on the flip side of the sticky for example.\n\n
• #54: There’s a wellknown acronym that tells us to INVEST in our user stories\n\nIndependent - this means that each story should be independent from others, as far as possible. Since we will use them to prioritize and estimate we want to be able to change the order of them, without having chains of stories coming along with it. \n\nNegotiable - this is not the requirements, just a reminder that we will talk it more later. The exact content will be discussed later. \n\nValuable - each story should give an user (or customer) value. The users doesn’t care if we use MVC or WebForms. That’s not content suitable for a story. Describe it in terms of value for our customers.\n\nEstimable - the story must be written so that you can estimate it’s size. You need to understand it enough for example. If it’s too big you need to break it down. Story points can be useful here - more on that later. \n\nSmall - an user story should be in the “right” size. Small but not too small. What’s the value for an user to edit the first name? Prefer small but not too small. \n\nTestable - how do we know when we are done? You need to be able to answer the question: “When are you done?”Write the acceptance criteria on the flip side of the sticky for example.\n\n
• #55: One way to break an user story down is to write different stories for different roles that uses the system. \n\nThe same functionality can be viewed differently by different roles for example.\n\n
• #56: If you start from a clean sheet it can be a good idea to start from the goal. \n\nWhat is it the user wants to achieve? Why are they using the feature?\n\nStart by writing down the “So that”-part\n\n\n
• #57: Slice up big stories to smaller. But make slices all through the system. \n\n\n\n\n
• #58: And before anybody even thinks it ...\nIt CAN be done. Your requirements too... \n\n\nTry to be creative in how you slice the story but do a complete slice of the system in each slice... \n
• #59: Try to avoid to describe processes or flows that never ends. \n“As a banking customer I want to control my account to see in and output”\n\nBetter is to write “closed” stories that is a snapshot or have a start and an end\n“As a banking customer I want to see my account status to know what have happened”\n\n
• #60: If there’s any special limitations for this story then write it as you discuss them. \n\n\n
• #61: Avoid to describe the graphical user interface\n\nThe user doesn’t want to pick from a drop down list - he want to pick a product\nThe user doesn’t want to sort a table - he want to sort the listing of accounts\n\nBy writing in terms of the GUI (or any other technical component such as database tables) we lock down our solution and loses the possibilities to discuss outside the technical group of the team.\n\n
• #62: Skriv för en användare och använd den användarens rollnamn. \n\n\n
• #63: Skriv “En användare kan söka bland sina konton” inte \n\n“En sökning kan ske bland kontona”\n
• #64: All these recommendations is actually summarized to a great deal in this simple template\n\n
• #65: Let’s try this. \n\nTake a function some well known service you use, like a internet bank.\n“Pay bills” for example\n\nDivide in groups of 3-5 people and try to break that down using user stories, to a size that can be implemented within 2 weeks. \nWhich activities is needed to pay bills?\n\nTake 15 minutes\n\nThen we meet again and compare and learn from each other. \n
• #66: Here are some support for the exercise \n
• #67: So, in a way, you could argue that the stories is out there...\n\nThe problem is that they are spread out in the head of many different people. Some parts of it will not show until you have talked for awhile\n\nSo gathering them could prove quite tricky. \n\nHere is a few alternatives.\n\n
• #68: One way is to use a technique called user story mapping. \n\nThis topic is a complete talk (at least) for itself, but very simply you set up a timeline for the big activities that an user can perform in your system. \n\nUnderneath you can flesh out the details in more and more advanced manner. \n\nSo for a system like Outlook (tm) you’ll have a top level row like: \nWrite Mail, Read Mail, Create invitation, manage calender etc. \n\nUnderneath each of them you’ll have details in those steps. For Write Mail:\nWrite simple textbased mail\nWrite HTML mail\nGet adresses from contacts \nAdd attachments\n...\n\nSo you get both the overview and the details on the same view. You can “zoom in” on the details when needed and “zoom out” to the overview when that’s needed.\n\n
• #69: To harvest the minds of many the best way is to write (or at least generate ideas) in workshops. Using the divide and merge technique we tried before for example. \n\n\n
• #70: If you have a hard time getting the whole project in the same room you should at least make sure that the core competences is gathered. \n\nThis will make sure that other aspects than you own will be considered which probably is good thing. \n\n
• #71: To be able to give an good estimate of how long time something will take us to create we need to know a lot about it’s details. What’s included?\n\nAnd you don’t. Never have. Never will.\n\nSo estimating in agile context is all around relativity. Something that humans actually is much better at than exact numbers. \n\n
• #72: So give me a guess - how big is this?\n\nHard huh? \n
• #73: Let’s try something easier...\n\nWhich is the bigger one?\nHow much bigger is the big one than the small one?\n\nMuch easier, right? \nAnd it turns out that humans are much better on estimating relativity than exact meassurements. \n\n“If you get a bad answer - ask a simpler question” - David J Andersson\n\n
• #74: To estimate the size of work in agile project we compare user stories against each other. \n\nWe set a set of points on them that really doesn’t have a meaning; called story points. The great thing about story point is that they represent how the team has percieved the size of the story. \n\nFor one team a story point can equal 1 days work, for another 1 weeks work and a third an hour. Really cannot compare the teams estimates against eachother\n\nAnd that is not important either - it’s the relativity that is! \n\nAll we know is that a story of 2 points is smaller than one of 3. And a story of 5 points is roughly double the work of the story of 3 points. \n\n
• #75: One of the problem with story points is that they can mean just whatever. Yeah, that’s right, the very thing I just told you were great with them. \n\nSo you cannot compare team against each other. But it’s easy to fall into that trap and start drawing conclusions from those comparisons.\n\nSo this had led a lot of team to ditch story points and instead talk about T-shirt size. Small Medium Large. \n\nThis concept holds some of the uncertainty and relativity that we need. \n\nThey are not exact and hence are hard to draw... Where story points is good. You have to chose. \n\n\n
• #76: One way of estimating as a group is using planning poker. \n\nSo pick a feature to discuss.\nThen pick a card, don’t show it to anyone. \nOn a given signal - show it to each other. \nIf you all have the same card - you have come to an agreement. \nIf not - discuss why you think different numbers and then do the exercise again\n\nThe special cards is:\n? - I have no clue\ncoffecup - my brain is fried. Give me coffee and a break before we continue\n
• #77: So the aim of planning poker is to discuss, as it is with many thing. \n\nThe actual number doesn’t matter too much - but the discussion does. This is where you clear you misconceptions and differences and clarify the feature enough to reach consensus. \n
• #78: When did a customer call you up and thanked you for the great estimates? \n
• #79: We can use user stories to plan how much we will be able to complete during a period of time. \n\nWhen we plan in an agile context we are balancing 3 things against each other:\nTime \nResources\nFeatures\n\n\n
• #80: Yeah right - for got one thing... \nQuality. But usually we don’t cut back on quality because that is very costly in the form of rework. \n\nAll these cannot be locked and unchangeable. \nOften we lock 3 of these:\nTime - let’s timebox and decide on when we shall be done\nResources - we often know who are in the team (and to what percentage)\nQuality - as above - let’s do the best quality we can\n\nAnd that just leaves functionality, right? Let’s vary that.\n\n\n
• #81: It’s now we’re happy that we have broken down our user stories into smaller parts so that they are in the “right” size for planning. \n\nBecause we can now lay all small user stories in a long row, in prioritized bussiness value and just take on as much as we will manage in the next sprint/iteration. \n\nThis is how I plan:\n\n\n
• #82: 1 - When do we want to be done?\n\n2 - Who are in the team? How much are we availble to the project?\n\n3 - Given those constraints... How much can we then manage during the next sprint?\n\nThis is called time boxing. Decide when you shall be done and let the features vary based on that. \n\n\nThis works best if you have a prioritized list to start from and those items are in the “right” size...\n\n
• #83: 1 - When do we want to be done?\n\n2 - Who are in the team? How much are we availble to the project?\n\n3 - Given those constraints... How much can we then manage during the next sprint?\n\nThis is called time boxing. Decide when you shall be done and let the features vary based on that. \n\n\nThis works best if you have a prioritized list to start from and those items are in the “right” size...\n\n
• #84: 1 - When do we want to be done?\n\n2 - Who are in the team? How much are we availble to the project?\n\n3 - Given those constraints... How much can we then manage during the next sprint?\n\nThis is called time boxing. Decide when you shall be done and let the features vary based on that. \n\n\nThis works best if you have a prioritized list to start from and those items are in the “right” size...\n\n
• #85: 1 - When do we want to be done?\n\n2 - Who are in the team? How much are we availble to the project?\n\n3 - Given those constraints... How much can we then manage during the next sprint?\n\nThis is called time boxing. Decide when you shall be done and let the features vary based on that. \n\n\nThis works best if you have a prioritized list to start from and those items are in the “right” size...\n\n
• #86: 1 - When do we want to be done?\n\n2 - Who are in the team? How much are we availble to the project?\n\n3 - Given those constraints... How much can we then manage during the next sprint?\n\nThis is called time boxing. Decide when you shall be done and let the features vary based on that. \n\n\nThis works best if you have a prioritized list to start from and those items are in the “right” size...\n\n
• #87: 1 - When do we want to be done?\n\n2 - Who are in the team? How much are we availble to the project?\n\n3 - Given those constraints... How much can we then manage during the next sprint?\n\nThis is called time boxing. Decide when you shall be done and let the features vary based on that. \n\n\nThis works best if you have a prioritized list to start from and those items are in the “right” size...\n\n
• #88: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #89: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #90: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #91: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #92: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #93: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #94: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #95: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #96: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #97: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #98: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #99: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #100: And with this in place we can now create a chart that shows us and everybody interested how far we have come and how much we have left. \n\nThis is called a burn down chart\n\nEach day when we meet we can update it and ... \n[CLICK] [CLICK] [CLICK] ... \n\nand show our progress.\n\n[CLICK]\nAnd draw the the trend at the same time. \n\nWe can see how we are doing against an ideal state (black line)\n
• #101: Have you ever heard a tester saying that they want to take part in the process earlier? \n\nI have and I think it’s superimportant. \n\nIf you want to move fast with small increment of the finished product then a steady focus on testing is going to be critical from the get go. \n\nBad quality will only boomerang on us and come back that the worst possible time. \n\n
• #102: When is a story done?\n[AUDIENCE]\n\n\nMichael Feathers; “This done thing scares me - code is in production or not!”\n\nWhen is something done in your sprints?\n\n
• #103: At my current client we have adopted a acronym that help us know when something is done. \n\nIt’s spells KLART in Swedish which means DONE. \nBut i’ve translated it here. \n\nCoded - the code is written and checked in\nDelivered - delivered to the right testing environment. Preferable a production like one\nAccepted - the team and the product owner is happy with the functionality\nDocumented - business rules, test cases and use cases is updated\nTested - the feature is tested enough for us feeling secure to release it to production without further testing of it’s details (some integration testing might be needed) \n\nIt’s not perfect. It need to be talked about a bit. But it’s a good start.\n\n\n
• #104: At my current client we have adopted a acronym that help us know when something is done. \n\nIt’s spells KLART in Swedish which means DONE. \nBut i’ve translated it here. \n\nCoded - the code is written and checked in\nDelivered - delivered to the right testing environment. Preferable a production like one\nAccepted - the team and the product owner is happy with the functionality\nDocumented - business rules, test cases and use cases is updated\nTested - the feature is tested enough for us feeling secure to release it to production without further testing of it’s details (some integration testing might be needed) \n\nIt’s not perfect. It need to be talked about a bit. But it’s a good start.\n\n\n
• #105: At my current client we have adopted a acronym that help us know when something is done. \n\nIt’s spells KLART in Swedish which means DONE. \nBut i’ve translated it here. \n\nCoded - the code is written and checked in\nDelivered - delivered to the right testing environment. Preferable a production like one\nAccepted - the team and the product owner is happy with the functionality\nDocumented - business rules, test cases and use cases is updated\nTested - the feature is tested enough for us feeling secure to release it to production without further testing of it’s details (some integration testing might be needed) \n\nIt’s not perfect. It need to be talked about a bit. But it’s a good start.\n\n\n
• #106: At my current client we have adopted a acronym that help us know when something is done. \n\nIt’s spells KLART in Swedish which means DONE. \nBut i’ve translated it here. \n\nCoded - the code is written and checked in\nDelivered - delivered to the right testing environment. Preferable a production like one\nAccepted - the team and the product owner is happy with the functionality\nDocumented - business rules, test cases and use cases is updated\nTested - the feature is tested enough for us feeling secure to release it to production without further testing of it’s details (some integration testing might be needed) \n\nIt’s not perfect. It need to be talked about a bit. But it’s a good start.\n\n\n
• #107: At my current client we have adopted a acronym that help us know when something is done. \n\nIt’s spells KLART in Swedish which means DONE. \nBut i’ve translated it here. \n\nCoded - the code is written and checked in\nDelivered - delivered to the right testing environment. Preferable a production like one\nAccepted - the team and the product owner is happy with the functionality\nDocumented - business rules, test cases and use cases is updated\nTested - the feature is tested enough for us feeling secure to release it to production without further testing of it’s details (some integration testing might be needed) \n\nIt’s not perfect. It need to be talked about a bit. But it’s a good start.\n\n\n
• #108: \n
• #109: To write tests or at least the acceptance criteria before you start developing a feature is a great way to verify that we have understood the same thing. \n\nAnd we get our definition of done in the process\n\n\n
• #110: To better understand each other we give examples. Imagine how hard it would be to describe how to tie a windsor tie. It’s much easier with a picture that is an example on how to do it.\n\nA good way to write test cases is to write so called Scenarios. \n\nExamples on how to use the feature. \n\n\n\n
• #111: One way to do this is give an example in form of a scenario, to clarify the story and to state our common knowledge\n\nThese sceanarios can be written in the template Given / When / Then (or translated into any of the nearly 40 supported languages)\n\n
• #112: One way to do this is give an example in form of a scenario, to clarify the story and to state our common knowledge\n\nThese sceanarios can be written in the template Given / When / Then (or translated into any of the nearly 40 supported languages)\n\n
• #113: One way to do this is give an example in form of a scenario, to clarify the story and to state our common knowledge\n\nThese sceanarios can be written in the template Given / When / Then (or translated into any of the nearly 40 supported languages)\n\n
• #114: One way to do this is give an example in form of a scenario, to clarify the story and to state our common knowledge\n\nThese sceanarios can be written in the template Given / When / Then (or translated into any of the nearly 40 supported languages)\n\n
• #115: One way to do this is give an example in form of a scenario, to clarify the story and to state our common knowledge\n\nThese sceanarios can be written in the template Given / When / Then (or translated into any of the nearly 40 supported languages)\n\n
• #116: Ta en av era stories från tidigare. \n\nSkriv ner 2 scenarion (ett där det går bra och ett där det går dåligt) genom att använda mallen från tidigare (Givet - När - Så). \n\nSamma grupper. \n\n10 min\nSen jämför\n
• #117: An user story is small written description of something that we will talk more about. Later. \n\nThey are the building blocks in an agile project where you want to delivery value iterative and incremental.\n\nThey are excellent for planning and testing separately \n\n
• #118: Please provide me with some feedback. \n\n[Here I usually do a retrospective-like exercise]\n\n
• #119: Thanks a bunch\n
• #120: Thanks a bunch\n
• #121: And so it’s over... Everything went black :)\n