Okay, let's get started. My name is Raj. I'm glad to see all of you here. How are the sections so far? Good stuff? Well, we're going to be prepared to be disappointed then, right? So... I'm only slightly joking. The reason I even submitted this talk was based on my experiences. None of the material that I'm going to present here is earth-shatteringly new or revolutionary. It's been done by thought leaders and disseminated to the agile community for over 10 years. But what I see is as a practitioner and as a coach with a lot of teams, especially with new teams moving towards agile, it's a constant struggle dealing with preparing stories for consumption within their sprints or Kanban, whatever the framework it is that they're using, as well as getting stories to done. So I thought, you know, why not just sort of submit this talk and narration is nice enough to accept the talk and here I am and I'm happy to see lots of people here. So, as I mentioned, I just want a quick show of hands as to who's... I'm assuming a lot of you are either with undergoing an agile transformation or working on agile teams. Is that fair? Yeah, lots of them? So how many of you are dealing with user stories and have... user stories? Everybody, right? It's nothing new, right? It's been around since the early days of agile. And how many of you have taken a deliberate approach to splitting stories, looking at splitting patterns for stories and so forth? A lot of you. There's nothing new here then. Just a refresher. So, in terms of... looks like the majority of you folks are pretty familiar with stories and splitting strategies. Just a quick show of hands and there's no shame here. Anybody who's not applied any splitting patterns towards story splitting and so forth at all. Good. Oh, there's quite a few. Okay. So those subset of folks, are you dealing with user stories at all and just still in traditional methods moving towards agile? Just curious. You're using user stories but lots of pain, right? Okay. Sorry. Okay, that's informational. So I will be introducing the idea of several different splitting strategies, of course. And for those who are already doing this, perhaps it's a nice refresher and you can chime in and maybe mention strategies but we'll start off the session and the outline is pretty straightforward. We'll just quickly ground ourselves and ourselves in stories, what the purpose is and then very quickly delve into story splitting strategies and how do we really prepare stories so as to get them to done in an efficient manner using these splitting strategies and then we'll have some time for Q&A. I want to keep this pretty conversational especially when we start coming to the different splitting strategies, I'll sort of throw out an example and we'll try to see how we can apply a given strategy towards breaking up these stories, if you will, into smaller bite size chunk. I want to make sure that this is pretty conversational and it's back and forth especially because all of you have done this quite a bit. All right, ready to get started? Yeah? All right. So thinking in stories, before we even talk about story splitting what the heck is a user story anyway? Anybody? What is it? User role, value, a chunk of what? A chunk of requirement. Yeah? Anything else? I heard somebody else scream something else. Would somebody say this? No? All right. So a user story is a lightweight expression of a given user segment or a user's need, the business proposition, if you will. And I know the most popular template out there is this connector format, a microns template, which is as it's such and such, as a certain user I want to invoke some capability, some function so that it achieves some larger outcome. So these are the essential considerations regardless of whether you stick to this format or some other format, it's sort of useful to consider those three perspectives.  What larger outcome are you trying to go after? And this is perfect even for, whether it's for software or even non-software initiatives. I deal with a lot of software as well as non-software transformations and we use these aspects to define our user needs in this specific format. So what I want to first draw to your attention is don't get too caught up, at least this has been my experience. I've been in the agile community a long time. My introduction was through Scrum and XP in 2003. What I see is there's, especially these days with the mass adoption of agile user stories obviously are central to most of these teams in terms of how they're thinking about requirements is there is this blind adherence to this format. The format is not that important. What's important is who the audience is, what it is they're trying to do and to what larger outcome. That's really the important facets of this lightweight expression. And how many of you have heard of Ron Jeffries, the three C's of a user story? Quite a few people, right? Every story, no matter how you express it in whatever format, needs to conform to these three guiding principles. The first C in the three C is it's a card. A card is essentially a token. And it's intentionally meant to be this little small index card because you don't want to write the entire requirement. Details are meant to emerge over time. They're not locked down up front. Very different than our traditional approaches. So I would be hesitant to call it a requirement because a user story is not intended to be a replacement for a requirement. It never was. I don't think it is ever going to be. The details will emerge in time. The second C in the three C's that Ron Jeffries mentions is the idea that it's a token for having a conversation. The real details of what it is that you're trying to build that capability emerge during conversations. And conversations are going to trump all other aspects of trying to jot it down into a format or put it into a Jira tool or whatever else it is. That's the second part of the three C's. And finally, and importantly at least it's been my experience that lots of stories in the teams that I'm working with that perhaps are small enough to fit on a card. People we do have these grooming sessions. You're talking about the details. But oftentimes the third C is forgotten which is every user's story should have unambiguous condition of satisfaction. You need to know what it is that needs to be satisfied to say that the story is done. And many a time I see teams sort of ignoring this aspect. This is critical because this is what's going to ensure you're getting to done. What's a practical aspect of this confirmation aspect from a technique perspective? We talk about acceptance criteria. That's really essentially what that is. But the important aspect is it should represent a shared understanding for programmers testers and business. Unambiguous.  Invest. Again, it's a normal idea. It's often good for us to as we write our user stories to think about the validity of the story through the lens of invest. Invest stands for the eye is independent, negotiable, valuable, estimable. I don't necessarily want to sort of go through each of these aspects.  Bill Wake is the guy who sort of came up with that mnemonic and definitely read up on it. What I want to focus on from our splitting perspective is two aspects. Every story ought to be valuable. Valuable to whom? Customer. Do you think there's no value in knowledge acquisition, meaning that sometimes you're doing some things where you don't really have true end user value just yet, but perhaps you're doing something that ultimate goal of end user value. So I believe that every now and then knowledge acquisition has a place in terms of being valuable. Right? And small, what does that imply? Within the iteration, somebody said. What else? Does one thing? Can be completed in one sprint. Smaller. It has a value. Yes, of course. Every story, if you look through a lens, has to be valuable. So oftentimes what it seems is at least in my experiences, when you say I want a given story to be valuable and I want it to be small, teams say it can be done.  Not necessarily. And small, at least in my opinion, humble opinion, doesn't necessarily mean your job is to split stories to fit in a sprint. Whether using time boxes or whether using flow-based frameworks, the point of small stories is to discover our direction and value.  The point is about getting feedback. The goal shouldn't be about trying to fit into a sprint. That should be the natural outcome but it should not be the root reason. I concur with you in the point that a lot of teams are really thinking about stories about I want it to split so it fits in my time box. That should just naturally emerge and I would challenge you guys to go back and think about it from a value proposition and a feedback proposition rather than think about my goal is to split it to fit into a sprint. That should be the consequence. We've talked a little bit about all of these aspects. Let's get into the actual sprinting strategies because we want them to be valuable be it knowledge acquisition or end user value and we want them to be small. But why small? Why should they be small? Besides the whole fitting into my time box thing because now I'm doing agile so you want QA to test feedback, okay? To be able to fail fast, rapid feedback because it's an iterative process and if we're going in the wrong direction we want to know that sooner, right? What else? Maybe you are releasing these incremental it's not fully featured but it's fully functional, that tiny sliver maybe your business cases you will deploy that into production and whatnot but that's not necessarily the business case for everybody but it's still valuable. It's about short feedback cycles, what else? What's that? But maybe the idea of breaking things up will make the implicit requirements emerge, right? That's a powerful reason to make things small. There's lots of hidden requirements that don't emerge if you don't break things, right? Another reason would be so we talked about feedback, we talked about requirements sort of emerge, implicit requirements emerging. It also means you're giving your product owner if you're in that sort of setup options real options to say I just want to do these certain things the rest are not that important just yet or maybe ever, right? It helps with prioritization and sequencing things there's lots of benefits to being small other than just the fact that it fits in the sprint in the sprint, okay? All right, any questions thus far before we sort of go into the different splitting strategies? Right? So you understand the purpose of things being small you understand what the notion of value so let's explore some strategies and as I've mentioned, all of these strategies are not new, they've been around a long time. In fact because of the time constraints that we have I'm going to probably just explore ten of them, right? I would strongly encourage you to go back and look there's folks, people like Kent McDonald who's actually speaking on some other topic has done lots of work on strategies and so forth so they're there and I'll share a few resources and my slides will be available so you can look them up. There's lots of other strategies beyond the ones that I'm talking about, okay? All right, let's talk a little bit about how requirements really emerge, right? I'm assuming in most organizations be it traditional or agile you are starting with some higher level business objective or outcome that you're trying to reach which you're then going to break it up into these broad big chunks of activity or features, call it features epics, I'm not going to get into the battle of whether you call it an epic or a feature these are big things, right? Big borders and you're going to sort of progressively, if you're in an agile environment, break them into these bite-sized chunks or these little pebbles which are then subsequently decomposed into if you're in a product development environment, coding tasks or if you're a non-software still there are some tasks that make up these stories, right? And as I mentioned an ambiguous conditions of satisfaction are distilled as acceptance criteria and these days through testable examples and I'll revisit that pattern later on as a spreading strategy but this is essentially what happens in some form in most organizations. True, not true, right? Absolutely, nothing new here. So we talked about a small pattern that I see and perhaps you can share your experiences especially with new teams, we understand we want to split these, we want to progressively elaborate our epics and features and so forth but what I often see is the breaking up of these big borders happens across architectural layers, right? People are nodding their heads. Absolutely, right? Because that's our comfort zone especially we don't have full stack developers, maybe I'm a DBA then there's a front-end expert there's a middle-tier person, whatever we're always breaking our things into what we know best which is our architectural layer, right? Not very valuable. Why is it not valuable? You can't test it and there's no business value I mean the end user can't do anything else. It doesn't give opportunities of prioritization. It's not a fully working thing saying that I finished my data model saying who cares, right? So the feedback cycle is deferred if you start breaking things but this seems to be a very natural tendency for folks to break this way also it sort of continues to keep that silo mentality, yes we have our role specialties but it sort of reinforces that I'm done with it, I'm going to hand it to somebody else we want to eliminate that silo mentality, we want to minimize these handoffs so the right way to approach splitting first and foremost is to, if we are doing horizontal slices by architectural layer is to look at it from a cross-cutting perspective. All the layers of whatever makes up your slice of the pie, right? If it's a traditional 3-tier app, user interface, business value database, some thin sliver, so that should be our first goal. If you're not doing it we have to make sure that at least we are starting there, right? So once we sort of get that in play how do I go about splitting these stories, vertical slices? So first and foremost I'll give you some of the most obvious ones, right? This strategy called workflow steps is useful when you're given story it describes a sequence of steps or activities that the user is going to have to do in order to realize that outcome that they're interested in. So I'm going to give an example, right? As a learner, somebody who wants to take a class somewhere I want to register for a class and pay for it using a credit card so that I'm better informed about Agile. Maybe I want to take a class on Scrum or something, right? So that's my story. Perfectly articulated, right? Conforms to all the different aspects you draw, what and how, what I want the outcome, everything, right? So take a look at the story and the way it's articulated I'm made sure that this story there are some workflow steps. What are some of the workflow steps you can think about when you read that? Registration. What does registration entail? Looking for a class registering for the class payment and what payment itself can be broken down into what? Payment method Payment method Maybe prior to payment reviewing my order, right? Post payment, maybe acknowledgement of a receipt, yeah, notifications. As you can see you're all smart people here and you're already broken down to like a million different things, right? When you think about all the things you said this feels like it's an entire application in itself, right? Expresses a nice little story if it's on a card, right? So again, some of this is pretty common sense. View the course, select the course review, pay notification, you get the picture. So some of the key questions you might want to think about when sort of breaking these down by workflow stuff this is pretty straightforward is can you take a thin slice through all aspects clearly you won't be able to finish all of this in a sprint, well you won't be able to finish this in two sprints, right? So we know we need to break this down. One tactic is can I sort of do a little thin needle through all aspects maybe it's not fully featured but can I do little pieces of it, right? That's one thing to consider. Short of that you say no, that's not possible for me to weave a narrative through all of those pieces but the other thing to think about is can I do the first one and can I do the last one because the real value is in where? Find the I want to take the darned class right? So maybe think of your stories in that manner when you talk about workflow. First step, last step can I do those? You should do that. And then all the other things we've talked about become additional stories that will come in time. Now this gives real options for a product owner because clearly these are all valuable things but especially valuable if you're doing the first and the last because that gives them the ability to actually sign up for the class Make sense? Alright, second one. This is fairly straightforward and perhaps you guys are using this all the time which is breaking up a story by operations, right? So in this one, and I want you guys to play along, right? As a training provider I will take the same theme. As a training provider I want to manage my course offerings so that learners can actually view them and sign up for some classes, right? That's my story, right? What are the implicit operations here? Creating my classes? What else? Deleting, editing? Yeah, absolutely. Searching, everything, right? There's lots of things that are happening here when you hear the word manage configure, administer right away, you know that you're doing multiple things, right? So operations. Break it down by that. And again, look at it. This down through this these different activities it seems common sense but also in addition, make sure that you're doing the most valuable one first in terms of look at it through invest. Is it really that valuable that I can do delete first? Not really, right? Is this that valuable adding a class? Yes, I would question that. Right? Why? Because I can easily have a flat file that I present and the ability for the user to select that. It's possible. Even edit. I can reupload a CS3 file, right? So you got to be a little more deliberate about how you apply these strategies, right? Yeah, so so my pet peeve with a lot of stories and I don't know about you guys is when I see stories that say as a user do this as a user do that, as a user do that what's especially of course is when I say as a developer do this, right? The problem with it is we're not thinking, we're blindly applying that format without thinking about who is this user? Is there nuances? There's always nuances to the different kinds of roles or personas in tracking the system, right? So in this case, as a learner I want to register for a class. Sounds simple enough but perhaps if you think about it, if I'm a learning organization there's the learners and there's the training providers perhaps and sometimes I might want to be able to register you into a class, right? So I'm doing the same operation but with a slightly different perspective, right? I'm a different role, right? So these kind of distinctions also have a powerful way for us to split things because they are similar but maybe not exactly the same and if you go back, if you're not doing this I would strongly urge you to go back and look at your story and say are you truly being deliberate about the actual user segment in tracking with your capability or function, right? So first of all, good? Useful stuff? You guys doing all of this already? So let me take a quick pause here. We enter workflow operations role. You guys do all of these? Good. Only two people? A few. So nothing new. No new learnings for them here. All right. So another simple one is data boundaries, right? So this is about when your initial story does interact with a certain entity but different facets, different pieces of data on that one entity that it's operating on. So in this example I present to you, as a learner I want to view course information so that blah blah blah. So what are the different pieces of data that you think that I can break this story up by? Say that again? And so on and so forth, right? Anything else? You mentioned something else? Course, the actual course, right? So maybe in this case the data boundaries are there's different facets, right? There's different attributes to what a course means. Maybe a first pass name and description is sufficient to get me going. And then the course agenda. Instructor qualifications. Is RADS qualified to teach this silly class? I don't know. So maybe the facility information. There's lots of things when you start delving into a given entity there's lots of facets. The question is, is it worthwhile for us to break it up along those channels so that we can get this going and then come back and add the additional details later, right? So one thing I want to sort of stop, pause here and mention. Just because these stories are small enough it doesn't mean it's one and done. What I mean by that is this is not something agile is not about saying I touch this, I finish this, I'm going to move on to something else. It never was. Agile is incremental and iterative. Iterative means you will be revisiting these things again. It's not a question that you won't ever come back to that capability. So it's okay that you take a thin sliver but you're going to come back and revisit it and add additional nuances to this capability, right? So perhaps that's a split that may well be worth it for you guys in terms of breaking things up. So now we'll look at a few more as we go through a few more examples that will get a little more complex in terms of these scenarios. So simple first and then enhanced again is a strategy where the initial story as this indicates has some base set of functionality that provides most of the value, either value from an end user perspective or from a knowledge acquisition perspective. Okay? So this is really tight to the whole notion of 80-20 rule, right? You heard of the 80-20 rule, right? Most capabilities, 80% of the value is realized by 20% of the work, right?  So as a learner, I want to see my past courses so that I can do something, right? So what is the base functionality that we're trying to provide here? Just show me all the darn things, right? That's my simplest use case. Of course, all of us are work on systems where we have lots of searching for things and then you want dynamic searching, yada yada yada. It essentially is adding complexity. I'm not saying it's not needed, but the question is, is it needed just yet, right? But I want to filter by topic. I want to just show me only the past two months. Whatever else your particular domain is, almost always you will find a natural base functionality that maybe it's not necessarily simple, but still maybe worthwhile for you to take a look and say, is it going to save me some time in terms of feedback, because I just at least get my basic search in and then I'll come back and make it more dynamic and so forth. Right? So, an ad hoc. Major effort. So this is again a typical pattern that you might come across. So, where there's a lot of effort that may have to be expended in order to get that first little bit of capability going, right? So as a learner, I want to pay for my class with Visa, American Express, MasterCard, yada yada yada. You get the picture. So where do you think the major effort here is? Payment gateway, right? I want to get that in place. That's my biggest effort. And that may take some more time. So be it. It's going to take the time it's going to take. Right? So the question is, when we're building a payment gateway, do we still want to at least pick one card to ensure that it works? Now the question is, does it matter whether it's Visa or American Express? Given my experience about American Express here, I'd say, yes, it matters because nobody wants to take American Express here. So maybe I want to just try mine with Visa, because perhaps that's more valuable, right? And then is it worthwhile then to break them up into separate stories for MasterCard and American Express and PayPal and whatnot? Why not? Okay. That's what I'm saying. Yeah, this is fine. We said we'll play with one. What is the next logical split after that? All the cards together. All the cards together, right? Absolutely, right? There's no point creating a profusion of cards, one for MasterCard, one for PayPal because the majority of the work is already done, that's the major effort. Maybe you'll just combine the all the others, right? You just don't want to have a profusion of cards all over the place with little, little micro stories, right? If it doesn't make sense, don't do it. Combine things, right? All right, let me just take one quick pause here. Still relevant? Yeah? Applicable? Right? Yeah. So here's another interesting one. Zero, one and many. So here, we're often dealing with collections of things, searching for things, deleting collections of things, managing collections of things. So as an online shopper, I want to delete items from a shopping cart. The zero, one, many principle essentially says doing nothing is the simplest thing you can do, right? You really need to do it at all, right? That's the zero case. And perhaps handling the zero case is relevant and the easiest thing to do. The only one thing is easier than many things. So you tackle that. Maybe I'll only allow you to delete one thing at a time. Yeah, it's a little painful for you as a user, but this is a short-term thing, right? So... Oops. And then so deleting one thing and then finally, you know, broadening it to many things. So this is another very common pattern to apply, right? As I mentioned, there's a host of other patterns. I've just selected some nine representative ones. There's one important one that I want to sort of spend some time on talking about next, which is about business rules, right? And I'm going to tie that with the notion of acceptance criteria as well, right? So any questions on the patterns we've studied so far, you know? Okay. So business rules provide a strong way for us to sort of make things smaller from a splitting perspective. And you guys mentioned that every story should conform to the three C's, confirmation being an integral part of a story. So... So... To tease out the business rules is obviously what you're doing when you talk about acceptance criteria you imagine, right? So if I had to sort of play along with you here, right? Say, I'm a product owner, you're my team. The programmers, the testers, the business me's, whatever. And as a user, I want to essentially create, let my learner log into my organization and create a password that's not easy to crack. Okay, that's the story. Now, what are the business rules there? I want to let my learners create an account and provide a password that's not easy to crack. You're my team. So, minimum 6 and maximum 12. Okay, that's one business rule. What else? Should be changed every three months, special characters, log equal to last five parts, should not be a dictionary word. So you guys have pros at this, right? What are all of these? These are business rules. Right? Now, what do I mean by example? So let's take the minimum character and maximum character thing, right? Exactly. If you're the tester types, they're always thinking the boundary cases, right? How can I break this thing? I'm mentioning the rule is one thing. Examples essentially exemplify the happy paths and the crappy paths for all of these different rules. And oftentimes, that's what test cases are made of, right? Are these various scenarios that exemplify either the rule being met or being broken, right? That's essentially an example. So Matt, when the guy who gave us an example, introduced his idea of example mapping and there's a nice blog post on example mapping. It's a technique that I use heavily in the organization that I am on in order to engage less technical people in the conversation on defining the boundaries of a story. Give me the rules. I'm not going to say acceptance test. I'm not going to say give and then, gherkin, blah, blah, blah, none of that. Just give me the rules surrounding and then engage the testers in the business piece. Give me examples because this is powerful as a program for me to guide my development. So we're doing this before development begins on any story. Lots of little things happen by thinking about this of these acceptance criteria in this manner. And also it provides a natural seam to break the story up. Maybe the last five passwords or change every three months is not important enough but let the product owner make that choice. As a team we're giving them real options by doing this. So that could be a natural seam to break stories into small things. And then also these rules are nothing but your acceptance criteria and if you get your testers engaged in this process early enough, perhaps they can give us these examples, illustrative examples and these become nothing but your acceptance scenario. Now whether you express them as give and then and make them automated tests, you can see the choices are limitless but this gives us a way to move towards the right kind of behavior in terms of how we want to get these stories to done while also providing a mechanism to split stories. Any questions about this? How many of you use the example mapping or some similar technique for gleaning acceptance criteria? There's a few. Do you guys concur with me? Lightweight powerful way to do this. When all else fails we have our spikes.  Perhaps the domain is such that there's just not enough information or knowledge intrinsic within the team that you can break this down. You spike it away to not necessarily split but essentially you're giving yourself a time box amount of time to investigate whatever it is question that you're trying to answer so that that information can help you break things up into bite size chunks. I'm assuming all of us have used spikes. All right. For those who haven't seen this none of these techniques are new and there's lots of techniques but I really like this particular one by Richard Lawrence. It's their story splitting strategies. I love that in one pager he's depicted all the different strategies that we've discussed and more but again even this is not the complete list. Look up look up look at the reference list that I have in the back of the slides lots of different strategies but this is a nice little cheat sheet. Richard Lawrence Richard Lawrence and you can just look up story splitting cheat sheet and you'll find it. So we print this off in our team rooms it's just a little useful for it to be there. So any questions thus far? All right. No not in this session but I can happy to have a conversation later. I have five minutes I want to sort of close this out with a few other thoughts. So over the session we've talked a little bit about the story splitting strategies and so forth. I just recently discovered this idea that Goiko mentions it's about thinking about stories whether they're good stories or whether these are really burger stories looking at it through the lens of what he calls the zone of control and sphere of influence. These are systems thinking concepts that he's very elegantly applied to stories. So before we talk about good stories, bad stories let me just quickly explain to the best of my understanding what this means. So zone of control is things that's fully within our control. So things like coding and testing things that we can do fully control of. Sphere of influence are things that we're not directly in control of but we can impact them in some way. So given these and then there's also the third aspect which is external influences that we cannot control at all. It's not in our control it can be really influence it. This is just third party external dependencies that we can't deal with. So given these systems thinking tools of a zone of control sphere of influence, what Goiko suggests is take a look at your stories the deliverables the I want part of a user story. The I want part of a user story and then he looks at the user need which is so that the larger outcome going back to that user story format he essentially what he's what he's suggesting is good stories are things from a deliverable perspective that we as a team can actually control but the outcome is not really our control but it's within the it's really we can influence it. That's what we're doing. We're building these things in order to influence the right outcome. So what Goiko suggests is good stories generally if you look at it through this lens should fall there within our control when I say our the teams control in terms of the what the functions are creating and they can impact but not fully control the the outcome. Bad stories and this is where I think a light went off for me because often times I see teams creating stories for the sake of creating stories because we have to fit these things and my scum master is shouting at me if I don't have at least 4 stories 10 stories in one of the case maybe. Now misleading stories will usually be in this quadrant where the team is in full control of the function the I want part also in full control of the the outcome as a database person I want to create a database table so that I can do a joint ok that is right here right? So be wary of those sorts of stories of micro stories, misleading stories fake stories in lots of different terms and when I saw these examples that makes a lot of sense so good stories usually reside in this quadrant. It's also good too for us to think about those stories that there's nothing we can do about certain things if I cannot control a certain delivered because I have a dependence on somebody else there's little you can do about it outside your zone of control then you really have unrealistic expectations and things that are just not actionable what do you do about those sorts of things often times we have dependencies with security teams infrastructure teams whatever the case may be the idea then is if you're starting to see stories in those quadrants we do the best we can to bring them here by splitting and so forth and if there are still some outlets that are here then you're assuming a risk because you can't control the outcome make sense? So I thought it was a useful way to sort of think about stories questions or thoughts I just sort of wrapped this up and leave some time questions that's an anti-pattern right yeah let me answer that question first right so you have lots of spikes in your sprints okay but typically right you have some I think to me it's an anti pattern because you're not doing enough upfront grooming right we looked at all these strategies as if that things are happening just in time and in order to have good flow in and a good rhythm you have to do look ahead planning right so some of you may have heard about 3 amigos sessions and so forth right you heard of 3 amigos sessions 3 amigos grooming sessions so 3 amigos grooming sessions is the 3 amigos or friends are business, testing and development a subset of those 3 facets are looking at your backlog and doing this decomposition ahead maybe a sprint ahead maybe just in I don't know what the right duration is but it's not all during your sprint planning because if you start to do this sort of decomposition just in sprint planning good luck with that because it's going to be a complete nightmare right so you are doing some deliberate upfront front just in time but a little ahead right to help mitigate some of those concerns if you start to see 50% of your story spikes that there's a deeper problem with how you're dealing with stories and your agile rhythm there's always going to be the idea of technical stories and then you have to build enough runway so as to actually build the stories so that's a good question and again you have to balance some of those architectural stories with your business value stories as first class citizens in your sprint backlog we do this all the time but be wary don't completely jam 10 sprints worth of just saying runway stories that I need to do this but a good question you still have one prioritized backlog you have enough trust or maybe you have a technical P.O. in additional business P.O. what are the strategies but you're balancing those concerns with your business value stories when is it going to be done right and that's a it's a difficult question it depends but let's talk a little bit about that because there's multiple answers to that question and no straightforward way to say I have to meet a certain date how do I there's uncertainties essentially spikes are trying to mitigate uncertainties to me even some of these stories are about mitigating uncertainties uncertainties in the real value proposition to make them small let me summarize and then maybe we'll have just another minute I'm getting the evil eye there to wrap this up so what do you export is definitely if you're not looking at invest definitely look at it look at all your stories through the invest model you don't be sort of stuck to that format it doesn't matter whether you use the connext format or not as long as your role what and why are being answered and also small stories are not about fitting into a sprint it's really about making sure you're discovering what really matters right that's how you present stories pretty and that's how you you presented to your business as why you need them engaged in this process it's not something that you do in isolation it's not just the teams job and it's not just the PS job either it's a collaborative effort again to somebody mentioned it's about fitting things into a sprint if you are adhering to these ideas they will naturally fit into a sprint I wouldn't go about saying I want to make them small because I want to fit them into a sprint that should not be the really the reason explore the patterns and be very very dog-manable about actionable acceptance criteria and scenarios and try this example mapping and see if that helps try that zone of control thing and look at your go back and try stories and say where they really fall it may reveal at least at least you'll be informed are these really valuable stories are they not so that's that maybe I have time for one or two questions maybe or yeah he's going to allow it so we've run out of time and we need to clear the partitions for the next session I'm going to upload this I'm going to upload it I tried this morning thank you for your participation and I'm happy to hang around here and answer some questions


Okay, we're back live here at EMC World 2012. This is theCUBE, our flagship telecast. We go out to the events and talk to the smart people who can find, extract the signal from the noise. I'm John Furrier, the founder of SiliconANGLE.com and I'm joined by my co-host. I'm Dave Vellante of Wikibon.org and we're here with Michael Dillatory, who's with SunGuard as VP of product management for the recovery services side of the business. Now, people might think of SunGuard as a disaster recovery company. I think you're sort of evolving into more of a availability company. And that's been, the big theme of this show is transformation.  So anyway, first of all, welcome to theCUBE. Thanks for making some time. Thanks for having me. It's great to be here. Yeah, so EMC World, is this your first EMC World or have you been to many? No, so I've been with SunGuard for a couple years now and so I've come to EMC World every year. This is a great opportunity to meet with a lot of customers. We're a big EMC customer, service integrator. So we work with EMC at a number of levels. So this is a great show for us.  You bring in a lot of technologies early, you beta test them. Yeah, so we were actually the first service provider user of Vblock and we've actually architected a lot of our cloud solutions, both on the production side and then on recover to cloud on the Vblock infrastructure. Yeah, that's been sort of a quasi game changer. Maybe it uses that term. It's kind of overused but it really has changed the industry quite a bit. But so let's get into your business a little bit. Talk about where your focus is, what your responsibilities are and then we'll get into some of the services and some of the trends that you're seeing. Okay, well my focus as head of product management for recovery services is I'm really responsible for two areas. So one are IT recovery solutions and then the other are work area recovery and worker recovery solutions. And so we look at it as not as a one-size-fits-all approach. Different environments have different needs, different availability objectives and they're architected on different technology so we have to supply a range of solutions to solve those customer needs. So there's a lot of talk about cloud, hybrid cloud seems to be really catching on. Whereas a year ago, our data showed not a lot of people were really pursuing it. Now that's changed. So what's your, what's Sunguards cloud strategy? Well, so our cloud strategy really breaks into two areas. So I'm not going to focus on as much on our production side. So our enterprise cloud, which is really more a place to run dev tests, to run production as well. So it's enterprise grade architected on top of VBlock. So you're going to have the reliability and the availability you need for enterprise grade applications. Then you're also going to have the protection based on Sunguards history of being that recovery expert, leader in the recovery industry, to be able to run enterprise grade applications. On the recovery side, from a cloud standpoint, we really approach the market as I said, from different customers or different places in their cloud migration. So the various things have been virtualized, various things are still physical, various things are running in a SaaS model and a hosted cloud model all over the place. And so it's not a simple environment. So a lot of people think cloud always simplifies IT and sometimes it actually makes it more complicated to make all of that available against the business needs. And so that's our strategy of really understanding what the customers are doing in production and provide tiered heterogeneous solutions to solve those availability objectives. Yeah, that's an interesting point you're making, Michael. I mean, at certain use cases and certain levels of mission criticality to put that infrastructure in, let's say, the public cloud is expensive. And so we really have to be careful about, hey, we got to go to the cloud. That kind of thinking is really a trap. It's alluring, but there's a lot of gotchas, right? Yeah, no, there's a lot of use cases where cloud makes sense and there's a lot of use cases where, well, public cloud makes sense. So there's a lot of use cases where private cloud's going to make sense and there's a lot of use cases where just virtualization makes sense. So we're seeing customers not move ubiquitous, just everything to the cloud. They're keeping some things in physical systems and the Unix environment, the mainframe environment, it's not going away. We're not seeing that. And so as you're deploying cloud, you still have to maintain that and make it all available and that's what our solutions do. That's really one of the biggest changes that we're seeing is that people are really starting to realize that those physical interdependencies are still needed and you need creative solutions to solve those use cases, in addition to getting the economic savings for those systems that make sense, for those applications that you're going to move to the cloud. You mentioned, we've talked about Vblock, there's also this move toward so-called reference architectures that basically are proven, but they have a lot more choice, different hypervisors, different communication systems, networking, different storage, and so forth, certainly in different compute. What's your take on that? There's a spectrum of a converged infrastructure. One's like any color you want as long as it's black, the other is a lot of choice, but there's trade-off. So what's your take on that for me? I'm so, as Sun Guard, it really is all about choice. So from a recovery services standpoint, customers are going to make decisions to optimize the uptime and effectiveness of their applications. So they need to focus on keeping IT out in the forefront and helping their business grow, helping their business reduce costs. And they're going to make certain decisions on how to deploy cloud. And I think these open architectures are really helping them do that, right? It's helping them make that dollar performance trade-off that they need and that customization that they need for their specific apps because organizations are very different. So while the Vblock definitely adds a lot of value and we've seen it with the reliability in the uptime, we're also looking at the open architectures as well to solve the specific application use cases. So talk about, as an old saying, backup is one thing, recovery is everything. Talk about what customers are pushing you towards from a recovery standpoint, whether it's RPO, RTO, how is the cloud affecting those business requirements? Well, the expectations of RTO and RPO have just compressed dramatically over the last five years. The expectations of what it costs to do disaster recovery and application availability has also dramatically changed. And so, but we're still seeing that the difference, there is still three specific tiers that you're going to see. You're going to see the mission-critical business. These are the crown jewels of the company. You're going to see the business-critical applications and then you're going to see everything else, basically. So a lot of people want to talk about multiple tiers, but I really think there's just three. And what's new with the cloud is more customers are willing to put their mission-critical applications both in the cloud and then recover to the cloud as well. So with that RTO or RPO compression, now even going to always on, going to under one hour, that's really the biggest change, is that now they're starting to look at doing the mission-critical apps in the cloud. And you're specifically talking about outsourced cloud, right? Yeah, so outsourced and sourced. So you have to think of Songard as two separate things. So we provide production services, which of course you have to outsource to be able to use it. We're a service provider or a hoster. And then from our standpoint, for disaster recovery, you could be in a hosted model, a service provider model with an IT outsourcer. You could be doing it yourself and you could be SaaS. We provide solutions to SaaS providers, the IT outsources into the customer's environment themselves. And so, but as you said, that you give pieces of that disaster recovery to us or you can keep pieces. So a lot of customers are keeping their mission-critical applications in-house and fully dedicated environments and then move everything else to Songard to get the economics and the reliability that outsourced recovery as the service solutions could provide. Michael, how do you handle the diversity of processes within your customer? You guys have a lot of customers. I don't know how many, but it's a lot. You've been around for a while. Yes, sure. And I'm sure there's commonality, but I'm sure there's also a lot of diversity in terms of how they handle security, how they report on incidents, how often they want to audit and how do you juggle all those different requirements and map them and align them with what you offer?  So there's a lot of, so I think it's very similar to how you think about IT architecture just in general. There's the kind of the open model where you have these different customizable modules that you can pull together and then you have the kind of one-size-fits-all. We are definitely not one-size-fits-all. In our history, our legacy has required that we bring different solutions that you can tailor.  So different customers are going to be running different applications, they're going to have different criticalities. So the same business, so you could have a retailer here, a retailer here. They're running very similar applications and they could have a completely different view about the criticality of their applications. They could have architected it completely differently and our solutions really work with anything. So we have professional services, consulting services that we wrap around it to plug them into our very open, very customizable and solution-oriented infrastructure and services. So there's also a lot of talk at this event and other events about big data. EMC kind of, actually SiliconANGLE started it years ago and then EMC picked up on it. I sort of joke, but it's sort of true, but so how is the big data, the whole people talk about the volume, the variety, the velocity, we've added the fourth V, which is value. How is that changing your business generally? And specifically I'm interested in the network requirements that you're seeing. So the network requirements with big, so one, it's not really my area of focus terribly, but big data with the network and what Sungar's trying to do is Sungar's trying to provide reference architectures, kind of a big data in a box, if you will. Leveraging the best-in-class technologies that EMC and others bring to the market with their acquisition of Green Plum and really deliver that in a service provider model. So most big data implementations are in the do-it-yourself model and since we're the service provider, we want to bring best-in-class technologies, best-in-class reference architectures to the forefront to make it kind of plug and play for the customer so they can really grow into a big data solution. They don't have to do the big bang investment. They can test it, see business value, and then scale as they grow. Yeah, okay, so I'm inferring from your comments that that big data trend hasn't permeated into your sort of recovery side of the business. No, not necessarily. It's really a very different use case for the data and so one of the things that you could think about, though, that we're starting to explore is different uses for data once it's off-site. So as you said, data protection is paramount. You have to have the data off-site. You have to have it in a secure location at the right recovery point objective and to know that it's going to be recoverable data. But then once you have it there, there's different things you can do with it. You can obviously do application recovery, which is a bread and butter. You can do dev test. You can do analytics on of that data. So a lot of the customers are now asking to say, how do I multi-purpose that data? How do I multi-purpose that second copy to say just so I just have one network pipe as opposed to many network pipes for the different use cases of that data. So that's some of the things that customers are bringing us into now. But how do you make that, how do I multi-purpose the use of that data so I don't have to ship it multiple times? So let's see, break out your telescope, maybe not the telescope, break out the binoculars. Let's not go too far. Let's look ahead, you know, two to three years. What do you see as the big changes that are coming in your business and how should customers be preparing for them? So some of the big changes that we're doing is really being able to worry free, guilt free, be able to outsource disaster recovery, be able to outsource your enterprise applications to our cloud, to our services. So, you know, so SAP hosting services on the cloud, Oracle hosting services on the cloud and you just don't have to worry. So, you know, and always version one of the technology, the customer's still going to have to do a lot for themselves. Version two of the technology, less and less, right? It's just behind the curtain and you don't worry about it. So as we start deploying these technologies, get more comfortable, customers get more comfortable, they see the use cases that it works, they see the stories that, my hope is that we'll be able to take more from the customer and save them more money so they can focus on their business growth and just, so one, saving them more money by just plug and play as we get these architectures, these reference architectures more baked and have basically less for them to do and then save more money. And the gate today is maturity, it's security, it's management, all of the above. It's kind of all of the above and then a lot of it is customer comfort. So as, you know, if you look at the virtualization market over the last however many years, right? They would just kind of toe-dip into it, right? They do the file system, they take the low-hanging fruit that made sense and then they started running enterprise apps on it and then they started moving it to the cloud so it's just a migration and as this develops, it's just going to, people are just going to get more comfortable. All right, Michael, listen, thanks very much for coming on theCUBE and sharing your perspectives, Michael Dillatory from Sunguards. John, we're wrapping up day three here. We've still got a ways to go though, we've got Howard Elias coming on, we've got David Goulden, so. Yeah, president and the CFO both coming on theCUBE. It could be exciting to get their perspectives. Actually, David Goulden. Good, so keep it right there, this is SiliconANGLE.tv's continuous coverage. We are theCUBE, we are live at EMC World 2012, we'll be right back.


everybody and happy Wednesday. Happy reveal Wednesday. So tonight we have a full room. We have Christine over here which was Maureen's captain this week and below her is Maureen. I know she's really anxious to see what all you guys have done for her. And then below me we have Michael Locopo and he's going to be our upcoming guest for the week which is really exciting. It's Locopo by the way. Oh Locopo. See now I always say something wrong and I usually get that apology in there in the beginning. You know I'm good at hatcheting names and stuff sometimes when I do the reveals but yeah but I try so yeah. I think we've all learned a lot of pronunciation this year. I think we have yes yes we have. I know and it was last week's unfortunately it was right before I got really sick and I realized that like half the time I was saying fill the wall wrong after I got like done with the life to cast so okay so at any rate now that we're through that I'm going to go ahead and say something real quick about wiki tree for anybody that doesn't know who we are and then we'll get to the good stuff. Now wiki tree of course is a community of genealogists who are working together on a single family tree. So in other words we collaborate to grow an accurate global tree that connects us all and it's free. The wiki tree challenge is our year long event and part of our year of accuracy where each week a team of wiki treeers takes on a genealogy stars tree and collaborates to make it more accurate and complete than it is anywhere else. So our goal is to improve our accuracy add more family connections and make more friends which we've certainly done. Now once again this week we worked on the branches of Maureen Taylor the photo detective and so here is Christine to tell you what we have found. All right okay so starting with George Edward Taylor unfortunately we didn't find any we didn't break any brick walls on his line but he was noted to be a commercial painter and it was also a career that his sons George and James continued. On Esther Knowles's line we started the week with quite a small tree to reference and only went up to her grandparents on her parents side but neither one of her grandmothers surnames were known. We did though find an interesting occupation for Esther's aunt Mary. Mary Esther's aunt was the daughter of Thomas Knowles and Martha Clayton. She was a cotton tenter and I'm sure we've all heard that expression being on tenter hooks and this is one of the places where that comes from. She was a cotton tenter which she worked with cloth and stretched it over a frame which was called a tent and they used the hooks to connect the fabric to that frame. On her line we were able to find the surname of Mary who is now a Shaw Cross and we broke brick walls on both the Knowles and the Shaw Cross lines so you have another generation of grandparents. On the Clayton line Maria is now Hallam and all of those people you see within that orange box are new ancestors for you. Wow. Now Samuel Clayton's brother he had a brother named Joseph. He was your fourth great-granduncle. He lived in Disney, England. He was attending the fair in May of 1813 when the Special Constable noticed that two men were pickpocketing and Joseph was one of the unwitting victims of the pickpockets. The constable saw them. He arrested both of them and they got sentenced to some hard labor. I think it was a year of hard labor for their efforts. Also on Esther's line Hannah is now a Tomlinson. She is the daughter of William Tomlinson and Mary Harrison of Lancashire, England and those are new ancestors for you as well on that line. Then we moved to Harry Wilson's line. Nothing new unfortunately on James Wilson. I know that was one of the brick walls that you really wanted broken. Unfortunately nothing was easily found there so that brick wall remains but looking at the McComber lines we knew up to Elijah and medieval Johnson. Also on this line was a will for Joshua McComber who was your fourth great-grandfather. Now he died actually without a will and his widow declined to administrate the state so William Nelson took over. Even though he didn't have a will his estate file ended up being 36 pages long and included an inventory like the fresh meadow on Blackbrook and the right pew at the reverend's meeting house. Different things like that. Yeah I found it interesting that they put live stock as two separate words instead of live stock. I also noticed that they differentiated between the kinds of hate like English hate and the fresh hate. And I did have to ask somebody what the difference was. I did not know. I have been informed. On Harry's line, sorry there, so through the McCombers now we have some more ancestors. So from William you can see how your tree just bitens out on that line. However Elijah's mother, we only have her first name. In these McCombers here this was Simeon who was married to Nancy Robinson. And again we only had a little bit of information. This is the herbivore tree that we were looking at.  I'm not sure how we changed that but it was changed. And your poly got changed to Mary and now this is what your tree looks like. So from Zephaniah Robinson all of your lines here go out to the 1600s. Wow Nancy has been a brick wall for a long time because she was born on Shon Island which is just privately owned now. So had a really hard time with that one. So this is amazing. A lot of these are, you'll see everybody is from Plymouth Colony or Massachusetts Bay. So a lot of these files are under the Puritan Great Migration Project. Wow. Now unfortunately even though this line took off and a hatches line did not. So we weren't able to find anything else on her line. And this is the Gifford line. So where we didn't have much of anything before now you have Giffords back to the 1600s as well. Wow. A lot of Plymouth Colony in Massachusetts Bay. And I think a lot of those profiles again are going into the PGM project and will already be sourced by other members. On Sarah Jane Kelly's line you are a descendant of the Mayflower passenger Stephen Hopkins. Sarah Jane Kelly's line? Yep. Through your third great grandmother Sabrina Chapman. Oh yeah Chapman. That was just Sabrina Kelly. Yeah. And then we get to your French side. So Joseph on Joseph the Set Side the parents were proven for Marie-Louise Remillard who is your fourth great-grandmother. Her back doesn't state her parents were Louis Marie Remillard and Cecil Smith who lived in the province of Quebec. Now she died fairly young and he remarried. There's a brick wall broken there. That's Smith. Yeah. And I know that you had asked about brother Andre and whether or not you were related. It's a folklore thing. You are. So my great aunt was right. Yeah brother Andre is your first cousin four times removed. I went to Montreal last in 2019. Let's just like skip back two years and went to the place. It's great. The Basilica? Yeah I went to the Basilica. I made my family climb off those stairs. Right. That's very cool. So he was the grandson of Joseph the Set and Angelique St. George which is your common ancestors. And then on his on Joseph's line and I was looking and looking at these lines there's so many Joseph the Set. But this is what we had started with was all of on Joseph the Set's line with Francois and Jean-Guiard. Now Jean-Guiard's surname was changed to Girard with an R in the middle. And now this is what the Basilica line looks like going back through to the 1600s. A lot of these you've seen. Those places in France. Wow look at all that. Yeah there's there's a lot and there's going to be a lot for you to go through and read up on. There's a lot of new people in your tree. When we get to Edmere bourgeois there was a lot of growth on the bourgeois line. Your second great-grandfather Julian, more than 200 new direct ancestors have been connected including Pierre Croisnier, the father of Martin Croisnier, a fiduara. Wow look at all that. I mean it goes back a long way in France. And that's what everybody loves about researching in Quebec because it's so easy and everybody is named as long as you can read the French. The records are all there. This photo in the bottom corner is Quentin Le Bourg which is where Pierre Croisnier was born somewhere between 1650 and 1620. Look at that. That's pretty amazing. 200 more. That'll keep me busy. I need a vacation. Just to go through the 200. Also on Edmere's line, we had a lot of help from Giselle Cormier who is our Acadian's project co-leader. She discovered Marie Leblanc who is a sixth great-grandmother and the wife of Germain Cormier. Now they were caught up in the deportation of the Cadians from what is now the maritime provinces of Canada. So between 1755 and 1764, the British came in and decided that all the Cadians needed to move on and be somewhere else and they deported a lot of them. Marie managed to escape and fled to Quebec in 1757. Her son, however, Francois, had been already deported to Georgia in 1755 without his family. He was married to Madeleine and they had already five children. And Madeleine fled with Marie towards Quebec. Now unfortunately, when they got there, there was a huge smallpox epidemic. And Marie, along with four of Francois and Madeleine's children, died shortly after arriving in Quebec. And then Francois tried to get back up to Canada, but he died somewhere around 1760 in New York. Wow. Yeah, Melanie's right. I need a sabbatical. I could give that terrible boss. I need a sabbatical. I have to apply for it. And then we get to the McDuff's. Angélique Le Form now has parents and more ancestors. Marie Louise is now a pru and another generation has been added.  So you went back on the Dessault line and the left form, but not McDuff. Yeah, that's a dead man. Yeah, unfortunately, yes. Irish. Ireland, yeah. Yeah, that's a bit tough. I think in that generation in Ireland, find the records. For sure. On the Messier's, Joseph McDuff's line goes off into the Messier's. Joseph Messier was born about 1802 in Verschere. From his first marriage, we found that his parents were Joseph Messier and François-Maurard de La Form. They had eight children, Joseph and his first wife. And then he was remarried and had no children with his second wife. But again, everybody within that orange box are new ancestors for you. Wow. So one of those little messages popped up and said that they had found a brother of Charles McDuff. Oh, okay. That's very cool. Everybody works up right up to the end, and I can only keep up for so much. Yeah, and the other thing that you'll find definitely looking through, Maureen, which I'm sure you've heard us say before, is notes. We try and keep our research logs right on the profile. So for those lines that were stuck on, or you were stuck on and we couldn't take the brick wall down, it may still have clues that will help you solve it hopefully in the future. Yeah. Well, bother of Charles McDuff is a good thing. This is a map of the migration of the McDuff's. So they came from, as you know, Ireland. Limerick. From Limerick, yeah. And then you can see the three stars over here, where they settled and married. Migration map. Little migration map there. Yep. And then we get to Melvina the Lot's line. The brick walls were broken for Ignace, Guillaume, and Marie-Joseph Gryffin, as well as Abner Wolcott and Catherine Gryffin. So you can see that they all have new parents. And again, on the Marie-Joseph's line, they goes back another generation and more. And into the P4 1700 there. And on the wall. Yeah. Yeah. And Abner has a father. And he is John Wolcott the Fifth. So there's four more Wolcots before him. And I haven't looked at I haven't looked at the sourcing on that. And those are, I think those are profiles that have been done by other people before. And then it says John Wolcott, the final one there. And then his wife, either Native American or captive white adoptee. Yeah. And again, I didn't look at the sourcing on that, but that's definitely something that you could look at and see if there's anything, see where that came from and see if there's anything else that can be added to it. Well, that's really interesting because that's a family rumor. It's that line in the Lot's. Oh, okay. I'll definitely have to look at that. Right. Yeah. Wow. That all came about. Cool. And then we have, I don't know if you've seen this one at all. This is the four generations of the Molot family. I didn't see it in the Pataki times. So they had a bit of a reunion here in Ontario and in Darlington, it looks like. Yeah. There's a lovely article about all the family and who had what children and all the generations that are still alive and the children that are still alive. So I love these old articles that have the genealogy built right into it. It's fantastic. I've seen the picture, but somehow missed the article. Cool. That's very cool. So all of that is attached to Napoleon's profile. So you can see that from there. It's a better copy than what's on the slide. Okay. And when we're doing our challenges, we always do space pages. I think we might have gotten ahead of the space pages this week. These are all the space pages that were done looking for Clayton's. And they still didn't find everybody that they were looking for, I don't think. But you can click on all of these and see the wills or who they're for and see if you can put the pieces of the bubble together. No. Greg wants to know if the Tuckett's near Nantucket. Not quite. You have to take a vote. And then you were talking about Covinclair. Yeah. And there's how you are related. That's your... That's very cool. Catechesis. And we can do this with our relationship finder. Anybody can enter two profile numbers in and you can immediately see if you have a direct relationship or a genealogical relationship through degrees of separation like marriages and stuff. We love our tools and apps and widgets. We love them. Yeah. We're kind of spoiled with our wikitree toys. It's good. And they're always... Somebody's always said they're making a new toy to play with, which is fun. Yes. Apps and different stuff. Yeah. We definitely really appreciate the people that are putting those together. Yeah. Yeah. And I had another note. I'm not sure what I did with it. You're also related through the Guillaume line to Camilla, the Duchess of Cornwall. You're eight cousins with her. That's pretty funny. That's very funny because my daughter went to a British school for a while and all the moms would sit around and talk about how many degrees they were from the crown. And I could just sit there and do it now, I guess. Yeah. Well, the French line, for sure. But the other one. That's very funny. Who knew? Who would have known? We know now. We know now. Yeah. Thank you so much. Well, we're going to go ahead and show you here just a little bit about the progress that Christine and the team made this week. Now, this is the brick wall chart that we start out with using as reference. So of course, for anybody that's not used to the fan charts, all of the yellow spots is where that first ancestor slot was open, what we call the brick wall ancestor. And then everything beyond it is just open. We, icing on the cake, we hope to get those filled out too. But all the little bees you see, you can kind of see in the pop out on the upper right. That's where we've marked that we broke down brick walls. So maybe not necessarily brick walls that you were stuck on or couldn't solve, but of course, you know, there's only so many hours in a day. We never get to all those lines. So it may just been somebody who hadn't had time to go back and research yet. So all of that was open. And then here is where you're going to see what we really did. And of course, you're going to see which side of the tree exploded just a little bit more than the other one. And Maureen, this is your final fan chart now on wiki tree. So that side is, let me guess, the pink is the French Canadian line. Yeah, that side has got some kind of full areas there. And moms is almost completely filled in. And that's nine generations. So I probably could have pulled a 10 generation on her easily. And yeah. Well, I just want to thank everyone so much. This is great. It's just wonderful to have another set of eyes, like literally a set of eyes, look at your tree and see if, you know, somebody can find something that you haven't. Because we all need that. So I just want to thank wiki tree and everyone who worked on the tree so much for all of their help. I got a lot of work to do now. Yeah, it takes a while to get through it all. It really does, honestly. But and we'll send you all kinds of goodies after you're done on here.  There were a lot of those that were early 15th century, 16th century. So yeah, you start getting back to where it's no it's all nobility. You don't you're not related to one royal line. They're just yeah, they're on there and people know about them. It's because they were they were notable. And you start seeing all the crests and stuff popping up for the different family lines. But yeah, and you know, and you'll see some in those instances, you'll see some profiles kind of in the middle that haven't necessarily been picked up by the projects yet. But the older ones definitely are. They always fit under somebody's umbrella on wiki tree. And the projects tend to them and research them and make sure that people don't you know, connect the wrong ancestors or anything like that. But yeah, you've got some super, super early lines. And it adds up to 200 real quick when you start looking back through the branches. Wow. Now I'm going to go through a little bit of what our collaboration is about and how they did with you and your week, Maureen. So collaboration, of course, is what wiki tree is all about. And one of the ways we collaborate what during the challenges we use a spreadsheet, like you can see on the left. And, you know, that way when you get 25 or 35 or and you actually were more than 30 people working on your week, people working at one time and around the clock, it's really easy to step on somebody's work or, you know, to feel like you wasted time if you aren't doing this and putting down the profile you're working on and somebody else has already done all the research. So we try and put our profile next to the name that we're working on. Now on the right, that's our G2G posts. So our genealogists to genealogists forum. And that's where we list out the eight great grandparents, which is where we start off from. And we allow people to put, hey, I broke a brick wall down here or I found this really cool document there. And, you know, not as much of the chatter goes on in the G2G, but you will see where those brick walls were posted.  And then the final way, which has just been really a key element for us is we are using Discord for our live chat function. And with us being a global site, we literally have people around the clock working on your tree. You know, there's no way one person could sit, we couldn't sit there and do this in a week's time. There's just people from all over the world. So we have people, you know, in Canada and Germany and France and just everywhere working. So they're in their own time zones and there's always somebody chatting. And, you know, we may go in there and just to cheer people on, but we may also go, hey, I need translations. You'll see on a lot of your profiles, they were awesome about pulling out those obituaries and articles and putting the actual transcriptions on your ancestors profiles. We have people that are really, really good at finding those obituaries. You know, not everybody's great at it. And so we can reach out and go, hey, I need an obit for this one. Do you have a minute? And they'll do it. We have a guy that loves transcribing really long old wills. So he'll sit there and just do that for hours. It's amazing. And, you know, there's all kinds of things that we use that room for, but it's really a lot of fun and it helps, you know, keep everybody's spirits up, keep the motivation going. And it's just a great way to collaborate. And now moving on to points, of course, it's not all about the points. We enjoy giving this gift every week of this year. But it does help us keep motivated. It also kind of tells us how we're going, you know, with our progress. And so we have two ways that we give points. We have, of course, those big bounty points. We give 10 points for the first brick wall ancestor found on each line. And then we give individual points for what we call the nuclear relatives. And so anything within one step of the ancestor sibling or child. And depending on how big the families are, now you saw that marine last week, Claire had some big ones. So there was a lot of those years weren't quite as big, but still everybody tried to make sure they did the whole family approach. And all of those kids were located if they were able to and added onto those profiles with sources. And so at the end of the week, we go ahead and we look at the total scores. Now there is Emma Macbeth, who's one of our captains, but she was also top performer this week. So congratulations, Emma. She made the MVP, which is most valuable player.  All did a really great job. And then I'm going to go ahead and put it on the score sheet so that you can see what the rest of this is about. Now, this is our score sheet that we get to look off of during the week. And of course, you'll see Emma up there and Sabi, this way you can see some of the different things we track. And the first number there is total points. Now, not everything that we do gets points. So say you're working on one of those space pages Christine was talking about, you don't get any points for that. If you get down in a rabbit hole, which we do sometimes, you know, and you're adding the husband and the kids and then his, you know, cousin or whatever, trying to track down names in a will or whatever and figure out how they're connected, you don't get points for that, but we like to do it. It helps the research. And so the 764 is just reflecting the points that they got for creating ancestors, creating those nuclear relatives or for those bounty points. Now, direct ancestors, there were 82 direct ancestors. You have a lot more than that, of course, because we connected to existing lines. So once we built out far enough back that we could connect to an existing line, that's how you end up with those hundreds and hundreds of people for the created relatives, the nuclear family 422. So that's a lot. You know, that's a lot of profiles that got made in one week. And then here, of course, we were bounty points. So we officially took down 26 of what we consider brick walls for a total of 260 points. Yay, you guys are so awesome. They do such a great job of this every week. They amazed me. Now profiles edited, there were 915 unique profiles edited in one week's time, which is just crazy. And then if you look at the edits themselves, so every time we go into a profile, and this is just for the profiles, and we add a date, or we add a source, or we fix something. And we hit say, that's an edit. And that's one of our contributions. Our system counts that there were 2,920 edits done just on your profiles of the ones that counted. So those those direct ones and whatnot. Really amazing job, just really amazing. So did did we meet your expectations for? Yes, you did. Yes, way beyond. Way beyond. I think the some of the brick walls I have are brick walls and they're never coming down. So I wasn't really sure you're going to break those because I've chipped away at them so many times. But he really extended my tree on the French Canadian line further than I had done. So thank you so much for that. And all the other stuff you found to that newspaper article with the 13 children and the family reunion. I never saw that. And my mom is still with us and she's coming over for Thanksgiving. And I'm going to bring I'm going to print out a lot of this stuff and show her she's going to be really amazed. Oh, that is amazing. That's great. He's going to love it. So thank you all very, very, very much. Definitely our pleasure, Maureen. Oh, and now Michael, it's your turn, Michael. He says, ooh, yeah, bring it on. Okay, I'll leave you now. So you can be the center of attention. Thank you for joining us. Mindy, I don't know if you saw Pat. Oh, she's got Pat had a question. She wanted to know if we have to bow down now to Maureen. Yes, yes, we do. I had missed that question. Sorry. It was through the Facebook post. Oh, it didn't pop up for me. Okay, so we're going to go on to Michael's and for a little bit of information for anybody that doesn't know. He began his genealogical research in 1980. So then doing it for a while, he's had his work published for the first time in 1985 and has had plenty more after that. He's appeared in USA Today, lectures internationally. He's experienced in Mennonite families, Pennsylvania Germans, mid-Atlantic research, genetic genealogy and more. So a really nice, diverse experience field there. He can read German script and has a particular interest in immigrant ancestry and is a retired small animal veterinarian. So that's great that you get to focus on your passion there now. Well, I might have to change that in my bio because I'm back to practicing medicine. For some reason, the need for veterinarians went really high during the pandemic. So I'm back to work. So I'm working at both my passions right now. I'm just really, really tired. Yeah, definitely no hours in the day for you, right? No free time. So what actually got you interested in genealogy? Well, it's funny because I tell people I started researching in 1980, but even before that, my mother was raised an only child and my father's family is kind of crazy. So there was not a lot of big holidays with cousins and whatnot. So every time we had events with my mother's family, it was all with great aunts and great, great aunts. And so I love these stories of these like 80 and 90 year old women when I was a kid. So I'd go home and ask my mother like, how was she my great, great aunt? And so I'd make these little charts and trees. So it just was innate. It's like I've been doing it since I was like eight years old. So it just blossomed from there. Oh, that's great. So if you had to pick one, who is your favorite ancestor? Oh, man, I don't know. That's a tough one. Obviously, I love my Pennsylvania Germans. I mean, I was born and raised in northern Indiana, but when I go back to Pennsylvania, it's just, you know, and genie, I'll just get this, but it's like, you just feel at home. It just feels like you should be there. So I love my Pennsylvania Germans. So I can't think of, I can pull one of them off my tree right now, but I gravitate towards them. Now, what kind of interesting stories have you found in your time researching your family? Well, my dad's, so the Italian side of family is full of murderers and attempted murderers. And so there's a lot of prison time and dead people there. But I do have a lot of black sheep in my family. I give a lecture on, well, I give various lectures on courthouse research and talk about the records people aren't finding. And I said, you know, you need to look at criminal records, because what we consider criminal today is not necessarily what we think of before. And I tell people, it's like, you may not think your ancestors are murderers, but if you're my ancestors, you usually are. So yeah, it's like those black sheep relatives, they leave great records. So I know. And I like to say, you know, they either sometimes had to be notable or naughty, or they didn't show up. But hey, one way or the other, you know, they left a record because of it. Yep. Yep. One of our Italians is putting a bag over his head, I think right now. Chris Ferriero's in the chat. And he's one of our Italian experts that he's not impressed. I don't think. Yeah, unfortunately, my Italian answers, do they do follow the stereotypical, you know, they weren't crime bosses. They were just had lots of bad tempers. So well, we should find lots of newspaper articles, and that'll be fantastic.  If you're looking for a newspaper, you got to be creative on spelling Locopo. So that's yeah, that kind of leads you. It leads you astray, because even with the OCR recognition, the A's and O's are hard to differentiate. So I'll see what you can find. Yeah, that's no, Chris. If they are, we aren't going to say yes. That's why we have our experts on finding things in the newspaper, though, they just have those ways of looking for everything that some of us can't find anything. Yeah, you really do sometimes. Now, when did you first hear about Wikitree? So, you know, I've known of its existence for a long, long time. And of course, you already know that I had a profile there, but I hadn't done anything with it. And I always go around and poke around in there. And I like the concept that it's, you know, it emphasizes source citation. And so that's fantastic. And that's the way it should be. We all know that as a genealogist. So I've dabbled in it and played with it and kind of, you know, looked at various profiles, but I really haven't jumped into it. So this is my deep dive. Well, this will be a lot of fun. We'll get to spread your brushes out on Wikitree. It'll be great. Now, what would you consider your most difficult recalls at the moment? Well, on both my mother's and father's side, I've got Pomeranian ancestors from the province of Pomerania in Prussia. And that is an area that experienced significant record loss. So if anyone can find a record from Pomerania that extends those, that would be wonderful. Those almost seem like hopeless cases. But I always tell people, I think all brick walls can be broken if you're persistent enough and creative enough. So those are tough ones. And I have on my mother's side a woman by the name of Mary Jane Wolf from New Jersey. I would love to know who her parents are. She's stymied me for 40 years. Wow. So what do you think it is about her not having records available? Well, she is consistently and without fail identified as being born in New Jersey, both by her census records and her children's records. But no one knows where in New Jersey. She's born in 1809 in New Jersey. She marries in 1830 in Indiana. Her last name was Wolf, which is really common. But there's not a single Wolf family in like a three county radius. So like she's just no one to even there's no candidates. And I've done some extensive work at like, you know, looking at New Jersey migrations to the Midwest, you know, play with DNA. And I've got some leads, but she's been my headache for 40 years. So yeah, I do have to say that we did take down a we almost made it to 50. It was somebody's 49 year old brick wall this year through a combination of traditional methods and then with DNA sources to back it up afterwards. But yeah, that one was a lot of fun. So what do you hope to see most about getting out of your participation here?  So I've I've really, really, really dug into my tree. And so I've kind of left very few stones unturned. So I'm kind of interested to see what people find that I haven't. Yeah, it's a lot of fun.  Well, yeah, like Marines that newspaper article and those kind of things just they add just more flesh to the to the bones. And so those are good too. I'm sure people find more more criminal records for me. Yeah, I can see it. Now they're going to be starting a contest. Yeah. Who can find the most who can find the most criminal records? Okay. Do we have any questions out of the audience tonight? I think I'm getting a little bit slow on the chat here. And you will see I will warn you, you will see some emails and stuff coming in, Michael.  Tuck them all away in a folder. I know. Sometimes I forget to warn people and then they email me and they're like, Mindy, am I supposed to do this? Or yeah, if there's anything like that, the paid staff will take care of it. And then the team will continue on with their research. But it does we can't stop the automatic generation. Okay, one big folder that'll work. Yeah, fine. Yeah. And find yourself it sounds like you're going to have plenty to do for the week to keep yourself from peeking. So yeah, yeah, it's true. My Italians are interesting too, because I descend through multiple Lacopo families. And there's still a lot of debate on whether Lacopo is one single family from one single town in Italy, or that there are multiple lines. But my I've got three, four, three, and I say look, different Lacopo lines, and they all go back to individual ancestors. So we'll see if but I've got to get access to Italian church records. So if anyone can have can access the Italian church records and the parish or Drache go for it. Now, Chris, I've had a question here for you about the Italian records on Antonati. Yeah, that's been fantastic. I mean, that's that's where I've been able to really flesh out my Italian trees years ago. So back in, I was in college, so it was put in the late 80s. The town in Italy, my ancestors come from the family, the families of your library had just microfilmed their civil records, they only microfilmed them up to 1865. And my ancestor, I mean, my great grandfather is the Italian immigrant. So I couldn't bridge that gap until they microfilmed more in the 2000s. And then when Antonati came along, it was just, you know, just floodgates opened. So yeah, fantastic. There's there's which is now which is now which is now but they're in Calabria, down south in the in the tip of the boot. Yeah, and I don't I don't have any particular experience with Italian records, but I know several of our Italian project people are really excited to be with you. Yeah, I don't consider I give like one lecture on like starting Italian research. And I know enough of the records to like dive in and find my people. But I would not even though I'm, you know, I've got an Italian great grandfather, I would not consider myself an Italian specialist. But yeah, it's a lot of it's, I joke about this, I had my, so my great great grandmother, she died in 1952 in Italy. So this is not ancient history. And I wrote to the the clerk in the town where she died in the late 80s to get her death certificate. I finally got it in 2005, because that's how Italians work. Wow, they get to it when they get to it. So they're kind of like the Hawaiians, right? Yeah, yeah, I've dealt with yeah, I've dealt with the island time. They send you the results on island time. Yep. I had, I've got cousins that still live there and they would go there in person and they'd be like, Oh, come back tomorrow. And then like tomorrow, come back next week. And that went on for about two decades. So that's very yellow says he has roots in Calabria. Yeah, very good. Lots of Calabrese out there. Excellent. My great, so I knew my great grandfather, my Italian immigrant great grandfather, and he always warned me to stay away from Sicilians because they're all crazy. So anyone out there who's Sicilian, I apologize. But yeah, the Calabresi and the Sicilians have this kind of like warring little thing, like it's like it's like the the Iowans and the Minnesotans and the Hatfields and the McCoys. That's like the Calabresi. They like they like to poke at each other. But that was my great grandfather's warning growing up. Now, I do have to ask you, do you have any pictures that are available for us to put on the wiki tree profiles? Because we do like to bling them up if we can. Oh, yeah, yeah, yeah. So do I put them up? You want me to put them up myself? Or since I'm not supposed to peek, should I send them? You can send them to your captain. Karen will be your captain. If she hasn't contacted you, she will be and you can send anything on to her. That would we would really appreciate it if we could use those. Good. Yeah, very much so. Okay. And then do you have any questions of us? Not really. It's like, so, you know, I've been watching the the challenges, but I haven't really tuned in. So I haven't really kind of seen like, you know, the process. And so I'm kind of very I'm really interested to see how it all works and what people find. And it might draw me in to be more of a participant in later weeks. So so no questions yet. Yeah, I'm sure you'll come up with some but that's okay. It's going to be a lot of fun. I know everybody's looking forward to it. I'm sure there are people that are already working on your branches. Now next week, when we come back, you guys make sure you tune in the same day, same time, Wednesday, 8 p.m. Eastern for the United States, and we will be doing Michael's reveal. And then we will be introducing Mary Roddy of the Applied Genealogy Institute. So you'll get to find out where her ancestors are from. And Chris is still making comments. And I want to thank everybody for showing up tonight. And thank you ahead of time for everybody that's going to be working on Michael's tree, because I know you're going to do just a fantastic job and find all kinds of great stuff for them. Yes, it's going to be great. And we'll leave it there. Have a great night, everyone.


Welcome to Toffy TV, this is the Edleton News Daily, two days ahead of the Maisie Side Derby and the Retain of Action in the Premier League at an empty Gullison Park. Carlo Ancelotti has held his pre-match press conference and give us all the details we needed. Fabian Delf and Yelimina are both going to miss this game through injury and there is a hope that they could possibly retain to action next Wednesday night against Norwich City, but we'll have to wait and see on that. Andre Gomez is fit and the manager said how important he was or is to the team.  He's crucial to the way Everton plays so Andre Gomez straight in there will be available for the game on Sunday and obviously you and I imagine will start the game and obviously will be crucial as he said to the way Everton plays which will be 4-4-2. The manager asked about his style and he said he will not be changing his style. They've come in this season and that's the style they've implemented and that's the style they're going to play and that won't change this season so it looks like it's going to be a 4-4-2 and Andre Gomez is going to be a big part of that and obviously the question now will be who will be part of him in the game without Delph, that combative player next to him. Will it be Tom Davis, will it be Guilffy Sigitson, we'll just have to wait. It certainly won't be Jean-Philippe Gabamon, but the manager had slightly more positive news on the his front. He said that he's going to be out for 4-5 months now. You've gone back a couple of weeks ago, he was about 9 months so for the manager to say 4-5 months that's obviously a lot better and I mean this and I've said previously I've sort of dismissed him now as an Everton player but that does help and he said he's a strong lad and he's recently had a baby as well and he said those kind of things really push people on and help them get better and hopefully Jean-Philippe Gabamon will. On the friendly's front, everything haven't had the friendly head of this game. They've had a bill that played Blackburn Rovers but the reason Calamante lot he said we hadn't played the friendly is because of the amount of injuries that we've suffered recently and he didn't want to get any more by having a competitive game but he has said the players are looking strong, they're looking healthy but obviously there are a few niggles and we've seen that already in the Premier League games that have been played to any you know you look at Arsenal and how they picked up a few injuries and that might have been who knows by they had a couple of friendly's so used to say they they didn't get pushed too hard or whatever it's there's no way of really knowing as they're going into this into this game how players are going to react you know we's we've seen three three Premier League games there's a fourth one just going on right now so far and it's it's clubs have looked at different levels so obviously it's going to be very very tough for Everton on Sunday but you know this could this could be the one that sees Everton get amazing side that happy victory the first one since what 2010 ridiculous absolutely ridiculous Calamante lot he also said that he's met the lockdown in Crosby and he loves Crosby, loves the beaches of Crosby, loves going for walks and he's mentioned this before but that's that's that's great because obviously that means that he's settled and he's got you know he's enjoying his home life on Maisie side and that's a big part of him being you know the manager of Everton football club hopefully for a long time so um there you go we'll have to wait and see what team comes out we'll be trying to predict that team in our start 11 video that will be up tomorrow if you want to watch the match preview that is out now me and Baz sit down to discuss the Maisie side that being what may happen or what may not happen we'll have to wait and see so check those videos i'll give this video a like subscribe if you haven't already and if you want more great videos including daily live videos join us over on Patreon the link is in the description thanks for watching see you later


My name is Victor Munoz, I'm the Task Force Desert Knights Operations Officer based out of Foss Pogetz, Poland. So here at Drowsk-Apomorsky training area we're conducting door gunnery and Apache gunnery. Purpose of the training here at DPTA is to produce readiness for both the Combat Aviation Brigade and First Infantry Division here at European AOR. Well we've just arrived here in theatre, we've been in the theatre a little more than 30 days. The gunnery that we're doing for door and Apache gunnery is both a semi-annual and annual requirement and doing it here at the beginning of our entrance in the theatre. Both validates our readiness and then improves upon those new aircrew members that just joined the team before our deployment here. It was a great exercise to both validate our interoperability with our Polish partners but also integrate air assets with the ground tactical plan. Although this is our first air gunnery operation while we're here in the theatre, we'll execute this again. This is both a building block to more advanced tables to increase our readiness and increase the complexity of our gunnery operations.