 Okay, good morning again. So now some of you will hear it for the third time, so we'll make very, very sure. So in case you didn't notice in the change in schedule or in the tweets, the original speaker for this session was ill this morning. And so about 90 minutes ago, I got a ping, I was still in my pajamas saying, hey, wanna come and help us out. So what I decided is we're still going to dive into this subject because this subject is, I mean, we could do an entire day on documentation. And you learn nothing over six years of doing this for large and small sites, more so than what just enough documentation means. So we're going to, because not the luxury of slide deck preparation, we're going to do more discussion. I'm really going to encourage you to ask me about particular issues that you're having or when we talk about a particular subject to dive in more deeply than into one or the other kinds of topics. But I wanna make sure I let you know, just in case you had your heart set on the original session or the original speaker and wanna take a quick look. I hope you will stay though, because I think that we're gonna find plenty to explore together. So in time to help you make the decision, tell you who I am. So my name is Diana Montalian Dupuis. I am the CEO of Amazing Labs Austin. So you might know Amazing Labs as being the Drupal shop in Zurich. Also they do a tremendous amount of core contribution. We, when I say they, I mean we. Core contribution, especially to multilingual because Switzerland has four official languages. One of them is not English. So multilingual for them is a major part for us, is a major part of development. They decided that they wanted to serve U.S. and Canadian clients, but didn't want to extend their shop or their dev team that far. So they decided to open a new business, a collaborative business here in the U.S. and that's how we came together. So this con is to a great extent the launch of that new venture. So over the year if you can be thinking wishful positive thoughts for me, I would really appreciate all the good vibes I can get. So before this, I used to own my own development shop and then I worked for Four Kitchens. I started there as a back-end developer and eventually became director of the team there. In between I worked as a team lead for the Economist project. So I spent 18 months as part of the Economist team. After that I joined a friend of mine who also owned another Drupal shop as VP of engineering and my role there with them was to develop the systems and processes from first intro to post launch. And now I'm doing this again for a team. So deciding exactly when and how to approach documentation and deciding exactly what we need to make sure we capture and what we likely don't need has been a major part of my career for the last five years. Also coincidentally, I happened to be a freelance writer for 15 years before I ever wrote a line of code. So good documentation with proper grammar and quality language is really, really important to me. So it just happened to be kismet that this was the session that they needed improv for today. Also I was a theater major the first time around and used to teach improv. So pretty much all came together to okay, yes, I'll be happy to stand up in front of a group of people and dive into this subject. Though I haven't had breakfast, but I had a lot of coffee. So I might talk faster and I talk fast to begin with than I usually do. Okay, so almost always but not always. Projects begin, the first document that is created for client interaction is the proposal. I am what you might call RFP averse. I have found over time that responding to RFPs is one of the most ineffective ways to. This always happens. This always happens. This, well it's been worse actually. I was in a demo for, I did work for the Wikimedia Foundation and I was in a demo and oh good, men suck and men are attractive. This is the, yeah. Apparently today, my friends can't decide apparently. Some of them are really pro-man today and some of them are really anti-man today. And of course now I can't remember how to close hangouts. So I'm trying to right click but it won't do it. See this is why I shouldn't have set up mirroring which wasn't my intention. Should we go back the whole session says yes they are. Thinking is not working. I am doing, okay if somebody honestly, if you think you can feel free to come up here and make this go away. Or unless we're having too much fun with it and we just want it to keep happening. We could see where he's gonna go with this. Please do. I use Vim so she will play handle this. Okay, see now here's something I've learned over my career. When in doubt, go to the command line. Always, always, right. I would be hangouts. Google talk play, where's the actual? I don't know, see there's the, I right click it all the time and it works. Okay so let me while he's helping us with this and while my friends are embarrassing themselves let's keep going with the talking about proposals. Okay so RFPs, a lot of strategy work gets done when I respond to RFPs right and it's work that obviously I don't charge for which is makes me a little more ambivalent. So my preference is that a client when even if I'm answering an RFP that I have someone who is knowledgeable about the project and inside of the project who can help me to strategize because 99.9% of the time the primary challenge of a project is not the technical challenges, it's the stakeholder challenges and it really helps me when I make initial strategy contact with a client to understand not just the explicit needs of the project but the implicit needs of the project. It also helps me form the tone of my response. If I'm responding to the engineering team because the engineering team is going to pick a vendor then I'm going to use lots and lots of geek speak because I want us to be speaking the same language. If I'm responding to, for example, the marketing director is the one who's making the vendor selection, I'm going to give the same information but the language that I use is going to focus more on the return on investment, on the visual environment. No luck? No luck. Awesome. Well, I wonder if I can't just, Chrome, okay, we did it. I also, in case you haven't noticed, have quite an assortment of gay and straight friends. Also, a lot of the four kitchens team is really super cute, so you might want to stop and visit them. Okay, so forming the language in a proposal of all of the steps that you will do, that is where I focus most on tone, okay? So in, now there's many, many, many, many approaches to first contact with clients in your proposal. I tend to favor keeping it relatively high level because when I'm estimating a project, when I am writing a proposal, never in the history of the world has more than 70% of what's in that document launched. Never. But never in the history of the world has a client forgotten any bullet point I ever put in a proposal at the beginning, right? And that's fair because at that point we're setting up expectations. It's a very vulnerable place for the client and for us, right? And in this place we're setting expectations but we're also trying to plan for the known unknowns and the unknown unknowns. So in the proposal I will always summarize the project in a way that shows one thing and one thing only. And that is I understand exactly what it is you hope to gain from this project, right? So that the proposal opens with helping them to see that we have communicated the most fundamental goal and how that goal will be measured. And I find that opening proposal documentation, proposal document with that kind of summary which usually takes me longer than the whole rest of the proposal helps us begin with a handshake, helps us begin in a place in which we either feel like we understand each other or we know we don't which is just as helpful, okay? So in the proposal document I think it's very important to include the overall feature set. Here are the things that we know are going to have to be built but not dive too deeply into exactly what will be built. If there's an RFP or I've been given some kind of strategy document from the client I will make sure that I cover each point that they have discussed. So a long time ago a career counselor told me that the best cover letters are the ones that respond to everything that the job posting is asking for. That's what you're answering. You're not, you're introducing yourself but you're also having the conversation. So the job posting begins the conversation and the cover letter continues the conversation. And I think the same thing applies in proposals. If they have mentioned that constant contact email integration is important then I wanna make sure that I mention constant contact email integration. Probably the most important thing if not the more radical thing for me in all client documentation including proposals is I tell the truth. If they're asking for something that's really crazy just really crazy and hard to do. I will explain not that it's crazy because it may not be, I might not understand what it is that they need but I will always include language that says here are the obstacles, here are the icebergs that I think this feature might run into, right? Here are some assumptions that I'm making. For example, I'm assuming constant contact integration is simply sending the email to constant contact and not a back and forth discussion that includes three different forms that identifies users by their role or their geography and then sends it to different lists. I will say these are the assumptions I'm making about how this feature will work and here are some of the things that I'm concerned about and will need to be explored more when we begin the project. And again, I don't wanna go too far in at that point because we haven't engaged yet, right? And the reality is that one of the primary services that every shop provides is strategy is the overall architecture of a project. So I want to build a framework but I don't wanna put up walls and windows and pick floor coverings in the proposal, right? And you'll hear me say this a number of times today just enough that I want the proposal to give them just enough to answer their questions which is always going to be the primary question is how much will it cost me? But I also want to communicate in the proposal the ways, the thinking that my team is going to use when we approach the project and then we know if it's a good fit. For estimation, of course, which is always part of it and a whole, I could do four sessions on estimation. Most three of them would be ranting and one of them would be solution oriented because projects cost what they cost, not what we guess that they're going to cost. Really, I could mostly just take a ball and throw it at the back wall and wherever it sticks on whatever numbers that I put up there, that's what I could say but really it's a guess, it's always a guess, right? So by saying these are the assumptions the guess is made on, here's kind of the breakdown of it, I never in my career have estimated a project by myself because I'm not, especially since I've been playing a leadership role, I'm not building the project. Therefore I'm not responsible myself for making sure that I build a feature in 15 hours. So when I do estimation, I always bring in the roles of the people who will be actually engaged in the project and have them blindly estimate feature sets and ask me questions and then I take their numbers and my numbers and when they don't meet, that's when we have a discussion. If I say I think something's about a day and someone else says I think something's about a week, then we discuss it because one of us doesn't understand exactly what we're looking for. Okay, so proposals. How many have, how many as part of your role are required to create that document? How many of you love that? Okay, and so what is it about proposals that is your biggest challenge or your biggest burning question or something that you're necessarily wrestling with, something that you're wrestling with in terms of what the proposal document should look like? Anyone? Okay, so the question is that in order, and tell me if I'm getting this right, in order for you to get where you need to go in a proposal, you end up writing seven or eight pages of a technical spec and make sure they get it and you get it and trying to make sure technical competence and that it's all there, right? But then are they really reading it and understanding it? Right, so full transparency and this is, I mean even in client demos this is a question, right? So I'm speaking engineering talk all the time, all the time, all the time, all the time. And then I'm talking to somebody who is not actually engaged in engineering but needs to make decisions based on everything that we're talking about all the time, right? And where's that balance point between too much engineering talk and too much, I mean dumbing it down isn't the right phrase, but that's a big mistake, right? Because if you take all of those seven or eight page technical specifications and you don't include any of that in your proposal, then the client's not making informed decisions, right? So there's that balance between those two things. And for me, it is if I can explain the concept in layman's terms, I do that first and I have to be able to do that. So if I can't do it in layman's terms at all then we probably don't need to, I probably don't need to include it at all, right? That probably doesn't need to go there. Most of the time I can. So if I explain it in layman's terms and then I add a couple of sentences that go deeper into it, then it's fine for people who want all the information to absorb it and for people who don't want all that information, they've gotten the layman's term for what I'm doing and then they can sort of skim over that. What I would say about doing that depth of specification during the proposal phase is that that is probably more for you than for them. Their question then really is vendor selection. Or is this a good fit? And so the technical competence will come across in your strategy and the way you talk about how you're going to build these features. But the seven to eight page technical specification is so that you make sure that that's there. Like you did understand it and you do know what they're going to do and that would come across in the language. So I would keep that document and then I would write one that is more four pages that translates it to layman terms with just the right amount of depth for each section depending on, again, the audience. Okay, anyone else about proposals? Yeah? Right. I don't know if you can. I do, right. So he's talking about the resentment aspect of proposal writing because of course you're engaging before you're engaging, right? And so how much effort do you put in because you want to give the clients what they need? That's really important. You want to give them what they need but you also don't want to take too much time away from the clients you're actively engaged in that you have now deadlines with. And then there was a sub question to that which is, what was the second part of what you were? Okay, strategy. How much educated? Okay, right. So the second part is how much strategy, because if you don't do it during, like if you don't do the seven or eight page document of technical specs, you're gonna have to do that eventually, right? So for me, the balance comes in and this is the next, we'll do that. That's the next document. That's not a proposal document. The strategy document is next. Now in my perfect world, this is what happens. I charge the client, my client's a flat fee to do what is the first two weeks of every project which is developed solution architecture, right? Now one of my pet peeves with an open source is that solution architecture is a professional role that people invest years in being able to use different formats and formulas for doing solution architecture. And in open source, we tend to do what my first computer science professor said, never sit down and type pound include and then just start typing code, right? Always draw out and tell out what your code, what your application's going to look like and then start building it. But often, I've often worked as part of projects or been in part of projects in which we're doing a similar thing. We just kind of start diving into it. Or worse, we start diving into specifications. The specifications are making a task list for a dinner party when you don't even know what the menu is yet. And you know, you're trying to make a shopping list when you don't have a menu. So the strategy document comes next. So let me answer the first part about the proposal process. So for me, I always try to make sure that I've had some conversation with the client. And what I do, when people contact me initially, I offer them 30 minutes of my time right up front. We discuss rates. I ask them about their project, about their budget. If after that 30 minutes, I'm feeling like this might be good for us, I feel a lot better about engaging then in the proposal. And then for me, it depends on, to some extent, it depends on the bandwidth that I have and the strategic, how this project is going to fit for our team, how it's going to fit with the client. But for the most part, I generally give myself a half a day to a day. And if I do that, then you've gotten this from me and I've gone as deeply as I can for larger projects, 200,000 to $500,000 projects, that's longer than it goes more towards a week. But for the $50,000 projects a day, usually is enough past that first conversation. So because I would tend to give more, always give more, I time box myself and that helps me. And it's worthwhile to invest in a project at that point where we fit each other. The other thing I will almost always do is ask people how many other vendors are being, are part of the process. And it's really surprising how often they'll tell me, you know, how many of us there are. I also am trying to get a feel for have you already decided, and now you just need two other proposals so that you can justify the proposal that you want to accept. I try never to be that in that position because that's work that I'm doing, but it's not, unless the building the relationship is really important, which is usually the case. I mean, all of work comes from relationships, right? And that's about documentation, I think an important thing to say. Documentation is the love letters that happen during the relationship of a project, right? You begin on your first date and then you go through the entire relationship and hopefully when you end, it always ends well. And your best friends afterwards, right? But the documentation is the tone and the language of the entire project, right? So whoever's writing the documentation, whether it's CIS admin or the project manager or whatever, the language of the documents actually need to also contribute to the positive process of the project itself. So the strategy document. In my perfect world, the first two weeks of a project are developing the strategy. Now the strategy is what will lead to technical specifications and include technical specifications. But what I'm really looking at at that point is how do all the pieces fit together and how do they align with the business goal? So here is a, in the proposal process, most people are looking at this is the goal. For example, let's see, we want to increase revenue by 50% by adding e-commerce to our site. That's easy to measure. But then they're going to be asking for things to be built that don't meet that goal. They don't contribute to the goal. Their other competitor sites have a really cool, interesting feature that they want to also include on their site because it's a cool and interesting feature. So when I'm looking at the strategy, I'm trying to bring the whole feature set together so that, trying to bring the whole feature set together so that the project has a cohesive framework that shows how the work that's going to be done can move forward the goal of the project itself. But it also lays the foundation for actually creating the technical specifications from there. I don't want to add a technical specification to that document, to the tech spec document or to user stories or whatever unless I understand why. So the strategy is why. It's been a common practice and it's my favorite thing to do is to have an engagement at the beginning of a project that's a fixed fee that is strictly strategy and then dive into development because they are somewhat, I think, two different mindsets. The teams are somewhat different. That doesn't always work out. But I want to reiterate what's already been said here. You'll do the strategy, whether you do it in the proposal phase or the strategy phase or the development team is doing it every two weeks because they don't exactly know what it is that they're trying to build. Always in a project, 25%, I think, of the project will be strategy and a lot of it ends up being non-billable, right? So the more the documentation provides a solid foundation for the team's development of a project, the less of that happens in a hurry up emergency kind of way. Now, here's what I don't mean by strategy. I don't mean a detailed description of absolutely everything that will get built on the project. That's not what I mean. What I mean from the strategy document is I'm a new developer and I come into a project. I should be able to read the strategy document, which I think would average about five or more pages for very large projects. I should be able to read the strategy document and understand what I'm building and why I'm building it. What is the purpose? What is my mission? What am I building? Not what am I building constant contact integration? What am I building? I am building the ability for the capturing of visitors to the site who don't necessarily engage in other kinds of ways that will get used in this way and the technology is constant contact integration, okay? So strategy questions, thoughts about strategy or feel free to share how you approach this, how you describe the project before you dive into the project process. Yeah? Christoph from Belgium, I wanted to ask if you do any behavior-driven development or if you've got experience with that and how you're approaching that. So you mean we're approaching user stories in the... So like, well, there's this whole movement like I think there's a few people in the room here that are doing B-Heads as part of that. Okay. Which is basically that you define a story before you do it and then like in such a way that it's easily testable afterwards and then you actually implement it and then verify that it actually does what you define. Do you do that or? That's a great question. The answer is kind of and so that's next. So that's the next format, that's the next, like the documentation of the stories themselves, the projects themselves, that's our next subject. So hold that thought. Okay, I'll have a plug, but I'll come back for that later. Okay, great. Did you have a, yeah? Right, exactly, exactly. So that's a great question. So their university is about to put out an RFP for a pretty good size project and when they're choosing vendors, they need to know that we've communicated correctly about what is going to be built and that you know what is gonna be built and it also helps to see that vendors have correctly assessed their estimate. Like if they've left out, that we're migrating from something to a .NET site into Drupal site and it's not part of what they're describing, right? It's important to be there. But at the same time, the university doesn't want to take on all of the burden of strategy up front so that the vendors are not taking that burden on. So there are three things that I think mitigate this and Zach Chandler at Stanford University is championing this in the Drupal community. And in the larger community, about creating vendor relationships that minimize the RFP. So the first thing that I would like in that situation is if you've seen that we have experience, we have experience in Drupal, we have expertise in Drupal, we contribute to the project itself. So it's reasonable to expect that we are qualified to a certain point, we are qualified to have that project, right? So pre-qualification. The first thing that was always helpful is an actual conversation where if there are say four or five vendors that are selected, a chance for you to ask some of those general overview questions and share what the fit is and for us to do the same thing. And by doing that, I think that a lot, maybe 40% of the process really happens there because it's not really just about how much it's going to cost, it's about how good is the process going to be? How good is the fit going to be? How effective is it going to be to work together? And so I think assessing that first really helps. And I think that a lot of the very busy and top level shops that you probably would want to engage in the projects are always happy to do that. And have this initial screening process. From there, the next step, I think, not necessarily diving deep, wholly deep into estimation, but the next step from there is, I think, maybe a secondary phase that can be the second and the third phase. But at that point, what you're looking for is a more high level understanding of all of the features that are going to happen, looking for the language of technical understanding. And I would not be afraid to ask people to tell you how they would implement it. You can say, this is what we want to accomplish. How would you suggest that we implement that feature? I love that because I know that when I ask that question, I have some latitude to be able to strategize and not just meet an expectation I don't understand. So if the proposal phase includes the ability to say, describe how you would do this, and then when you're comparing vendors, you're comparing approach to approach instead of price to price. And I think that tells you a lot more about them. So an initial conversation to just assess fit and rule out general things that might happen. The second one is a response that doesn't have to include absolutely everything but covers the overall approach to the project and invites people to be creative about the way that they might approach what you want to have done unless you already know, in which case you want them to respond exactly. And then the third phase is then price to price. Then it is assessing, okay, so these are the three that we've really liked. Here are the approaches that we really liked. Okay, they're really expensive and they're really not. That's when that piece of the conversation comes in. Does that answer your question? Okay, good. Yeah? Okay, and he spoke, he calls it an expository sketch. I think if you Google him, you'll likely find some of his sessions or talks and that creating the expository sketch. I have, I will tell you the secret, as a vendor I would do anything Zach Chandler ever asked of me, ever. Because I trust, I mean, and I have done a lot of work for projects I didn't get in that particular way. And that's okay. Because each step of the process, I know exactly what I'm contributing. I know that there are two other people who are doing it with me, not 10, but there are two other people. So now I'm giving, we're giving people exactly what they need from the process, I think, yeah? Okay, so any other questions about strategy? Okay, so specs and user stories. This is a three day session here. Bless you, who has experience or works in a scrum shop, an agile scrum shop? Who has experience with behavior driven, with testing focused stories? Who is primarily waterfall? Okay. So there is a huge, huge Grand Canyon size chasm of potential ways of approaching, describing the tasks that need to happen on a project. That's a major part of the documentation. So I'll tell you that my bias is towards user stories because up until now I have worked primarily on scrum projects. And so I have approached projects by building a ready backlog, which is what agile scrum does, writing user stories. Amazing and Zurich is agile, but not scrum. So they are doing this very interesting, they've been doing this very interesting combination of technical specifications as tasks that are given to the development team, but still allow for an agile approach to the development itself. And then I've seen projects in which there's, you know, Gantt charts and people and launch, what? I've, to be honest with you, I've not seen any of them always succeed at being able to define a project and make it launch exactly the way they want to on time. This is a creative dialogue. User stories are a creative dialogue. So one thing it depends on is the team doing the work. What do they need in order to know every day when they work on the project? What do they need in order to know exactly what needs to get done? That's, that I think is the most important goal of the document of what needs to get built. For, I will tell you from my experience, which is also closer to behavior driven, the next step for me is to build the document called, it's called an artifact is the ready backlog. The ready backlog does not include technical tasks. The ready backlog includes user stories. So user stories as we're using the constant contact email integration. As a new, as an anonymous user, I want to be able to receive regular newsletters so that I can stay informed of opportunities or offers made by this client. And then once I've written the user story, I write the user story for the whole project as it's going to be built. So notice I'm not saying I want to put, I want constant contact to be integrated with Drupal. That's not in the language. What do we do? Oops. So many other teams would now make the list integrating constant contact would create the list and you would have the Gantt chart of the list. I think that if I talk about this, we'll have to stop, get lunch, come back in. If I talk about strengths and weaknesses of these different kinds of documents. So what I would say instead is that the document that the project works off of is three things. It's alive and organic. That's one thing together. I'm sorry, I stuck an end in there. It's alive and organic. Whatever document is conveying the tasks, the goals, the day-to-day work of the project needs to be a living document because it will be, it will change. It will absolutely, even if it's a fixed big project where you know exactly what you're supposed to do and you're doing change requests, it will change. No project ever in the history of the world has started with one task list and launched with exactly those features. That doesn't happen because as things get released, as things get built, more information comes out and sometimes the needs change and sometimes the technology doesn't cooperate. Often the technology, sometimes the technology doesn't cooperate. Or you learn things, especially if it's a previous project. So the documentation of day-to-day tasks of the deliverables and how the deliverables get to be built needs to be organic and a living changeable approach. This is why user stories where you're expressing the goal allows the development team to be able to make engineering decisions about the best way to implement it, right? So it needs to be living. It needs to be, in my opinion, it needs to be collaborative with the people doing the work because they're the ones who have the best idea of how much effort something takes to build. This is very radical. I have this kind of like, and get pushback on it and I don't think I'm right, but I have had the best experience with that. So in Scrum, for example, if we say the constant contact integration story, then the developers have to agree about how long in a sprint, how actually we use the Fibonacci sequence to measure effort. But regardless of how you do that, my personal opinion is that that documentation needs to be organic and changeable and it needs to be collaborative. And even if it's collaborative, strictly that the project manager and stakeholders more so than the team. However the collaboration happens, collaboration on that document will make better outcome always. And then the third thing is a way to be able to assess when it fails. So if you're creating stories or tasks lists or technical specifications, however you're documenting the daily work, it does it work? Is it right? Did you get it right? Like does it take you three, did it take you three times longer most of the time or did you, when you made a task list that include 10 tasks were there really 20? And if the team is doing those 10 extra tasks, they need to be in the documentation after they're done or in my opinion before they get done. Or if you're using JIRA, right? A ticket for everything. A ticket for everything in JIRA. That the team should never be building something or working on something that there isn't documented. Like I could not say this enough, this would should be a tattoo on my body somewhere, right? Never be working on something on a project, putting an effort that isn't documented somewhere, tracked somewhere. Because at the end of a project you really don't know the investment. I include time, like there's a lot of communication time that needs to happen. I include strategy time. There's a lot of time that it takes me to be able to figure out what and how to build it before we even start building it. So this document, livable, collaborative, and then post-edited, make sure that it accurately represents the project. So I'm gonna ask for questions, but I'm a little afraid, we're gonna go with this. What do you think about specs? And when you say people, do you mean stakeholders, product owner, development team, who's the people? Right, okay. That's a really good question, saying, so some people need to know progress, how are we making progress? Some people need to know the business goal, like how we're doing the business goal, and he's saying the developer just needs to know constant contact integration, right? So I would say that I, my personal preference is to meet in the middle. I always want the developer to know why, what's their goal. Because once they dive into the technology of just constant contact implementation, then there's going to be other opportunities, right, for the way that this might be implemented. And if they're not engaged with being part of the people having the discussion, I'm gonna lose an opportunity for innovation. On the other hand, I don't want the development team to have to have conversations with the stakeholders about how and why some of the constant contact versus mail champ versus whatever. So the intercessor to me, there's where quality project management comes in, right? And the way, in the setting up the communication systems, I always have and still do at AMAZE, there is one person on the client side that is the product owner. That is the person that we communicate with, predominantly. They have access to whatever documentation we're doing, they have access to that. Beyond that person, stakeholder management is predominantly the responsibility of the product owner, not of the development team, right? So that what we try and do is create a cohesive development team and the development process on our side, which will have project management or technical team lead, or sometimes me early in the project, as the person who is sort of between or including, I include the development team in the conversations as needed, right? Sometimes I need to have the Node.js expert in business conversations because I don't know actually what the range of possibilities of implementation for how we might handle asynchronous feeds and how fast that's going to be, right? So I will make decisions or the project manager or the CTO in the case of Zurich will make decisions about how to include the team in thinking and then on the client side, the product owner makes decisions about how to include stakeholders. So then the documentation should be readable by the product owner and the development team and include the technical information, but also the why. That's my ideal world, but oftentimes it means understanding the why and then creating a task list, constant contact implementation. But in my perfect world, it meets at that balance point, not too much, just enough, always again, just enough, just enough documentation to understand why something's gonna be built and how it's going to be built, right? No more, no less, which is, I'll spend another 20 years doing this and still not really actually figure out how to do that elegantly, but that's the goal, okay? Anyone else, huh? So when you say that you're doing user stories, are you doing an Agile Scrum methodology? Okay, so a couple of things, first of all, so she's asking that the backlog, that these stories that you described the project, you have duplicates, you have things that sort of say the same thing, you end up having a whole bunch of things that probably aren't gonna get done because everybody is going to build Apple.com in the beginning, right? We're, I think this is what's gonna go and then as it gets closer, we realize no, we're going to launch the actual minimal viable product when we launch, right? And the gap between minimal viable product and Apple.com is expectation management, right? That's where projects hit the rocks, always, always, always, right? So the first thing is the Scrum Master, that's what the Scrum Master does. And if the backlog is rambling in too much, then I would, that's a Scrum Master's problem, right? That's the first and last thing I would say about that. That would be the Scrum Master's problem and the Scrum Master's weekend, so that. But also, the task list is a guide in very few projects. I've never worked on a project in which it all gets done. It doesn't get done. You get the highest priority things done and then you make decisions when the time left over. So by prioritizing, these are the most important things. Like if you have a list of tasks for the whole project that is not prioritized, you're kind of screwed, right? Because it's not all going to get done. So again, that document is living and changeable and I should have added forth prioritized, right? Know the most important things to build and build those. The ones that are at the bottom, maybe those are phase two. Maybe in the end, you really didn't need them, right? I mean, every time I go grocery shopping, I come home with 30% of things that I didn't actually need to bring with me. If I'd gone through and cultivated my groceries and put back the things that were impulse buys before I left, I'd save, I mean, I could get a massage every month just based on what I'm saving, right? So there's process of cultivating and prioritization. But if you're focusing on this living document, whatever it is, if you're focusing on making a collaborative, but also prioritizing it, right, every week, it's like, are these still our top priorities? Is this still the order that this gets done? The things that are at the bottom, they feel like stress, right? Because oh my God, oh my God, oh my God, we only have one week and there are 700 tasks left, right? But scrum was invented, this is my favorite phrase, is scrum was invented because reality refuses to bow down to power, right? You only have as much time as you have. That's it. I mean, you cannot pull time out of time, except unless you're Dr. Hu, in which case I want him on my team. So, prioritization of this, and then the setting expectations as it go, but there's also some zen of the stuff that's at the bottom is somewhat of a question mark, which is why fixed bid projects with very specific technical specifications right out will kill me, basically, if there's going to be a death, that would be my death. But even then, still not everything's going to get done. And also people don't, when you're engaged in a very big project, you think something is very important and then at the end it doesn't seem as important. And so it happens on both sides, right? So some flexibility happens. But the really one word answer to your question is scrum master, this is scrum master, yeah? So I talked about a plug in 10 minutes. I'm going to have a session about walk hub, which is an open source tool built on top of Drupal that allows you to create step-by-step tutorials just by recording them. But I think it's possible to do much more with it because it's based on a testing framework. So you can use it to actually also test those user stories. And I would like to have a discussion. So if you're anybody who's interested, I would like to have a discussion about how you could kind of pre-define user stories like in step-by-step descriptions, kind of like in a B-hat way, or you know, behavior driven development way, and then turn those into walk-throughs that are living documentation. So because it's a test, you can run screenshots automatically and you can update that. So you can verify if your previous user stories are still working, there's a whole bunch of other stuff. Perfect. I'll leave flyers at the door. Is there anybody who wants to volunteer in exchange for a really good Belgian chocolate to collect? I couldn't bring that. Like this was already an adventure with the heat. In exchange for a really good Belgian chocolate to collect name cards and to bring them to the booth, that would be really awesome. Is there any volunteer? Like for, I'm sorry, for name cards for a beta invite. That's the most important part. Okay, so find him, someone. Find him, volunteer, find him, okay? Because I have to go upstairs because I have to go set up. Thank you. Okay, and good, and good. See community development in the middle of the session. Perfect, great, so good. So this will be a perfect transition. You want to dive more deeply into that. There's your opportunity plus other, right? This is a big discussion happening here. So the next couple of pieces are quick, right? Because again, just enough, development documents. So if I'm, think again, I'm new on a project. How do I set up my development instance? What's the development username and password? There needs to always be documentation. I always have a group of files, a group of documents for every single project that the design of that goal is the design of those document collection is that someone can walk in, pick up this project and within a day or less than a day within a couple of hours be set up to go, right? So making sure that there isn't like the person who sets up the development process over here who doesn't capture that information, right? That is the most essential to me of development documentation. The most essential thing is what I unfortunately and macabre say is the hit by a bus. The hit by a bus document, okay? You have development team working on it. Someone gets hit by a bus. Can a new developer come into the project and know what they need to know about the project and about decisions that have been made, okay? So that's easy for just enough. Data, you can make data modeling and with Drupal 8 it's gonna be even more important where you describe the data architecture. You can make beautiful charts and graphs and whatever or you cannot do it at all. I would vote for neither. I would vote for neither. I do think that early in the project, data architecture for not just describing the content types but also how entities will interact with each other, what does the data architecture look like, right? Some documentation of data that's not going to take a person a week to draw but exists because I can't tell you how many projects have gone wrong because now we need to change some of the way that data interacts with each other but we didn't design the tables to be interactive. We didn't connect to the data and Drupal 8 is gonna make that a nightmare if you do not do it. So some documentation that describes and here this can be strictly developer talk. This does not need to be put into layman's terms or whatever. The development team needs some engineering thinking about data on a site and data is entities and fields. Also API forms and what you capture and what you put out. Not diving into it too deeply, not ignoring it, something in between. The how I don't know because I keep experimenting and doing it completely differently than I did it last time and I still haven't settled on anything. So I have no, I have not unfortunately, I've done it, I've overdone it and I've underdone it. So I would ask the developer, the development team what they need. That's who I would approach. Okay and just enough feature documentation. So if I'm delivering a feature to a client, I wanna do two things. I wanna show, no I wanna do three things. I wanna show them how to use it. I want them to use it before it launches. Use it in the way that they intend to use it. Give me feedback. As many people as can do that is great, but definitely that. And the third thing is I want to deliver documentation that performs the same service that just the hit by a bus service on the other side. Which says, so now if somebody on the user side suddenly gets hit by a bus, isn't it terrible at 1045? Is this what happens if I don't eat breakfast? I start killing people in my improv session. Gets hit by a bus. That they know how to use their feature, right? Not a thesis, right? Not like in depth training, but also not nothing, right? Hey, here you go. Here's this thing that is custom built for you and no one knows how to use it and we've shown you and yay, right? So just enough feature documentation. For me, a feature is not done. It is not launchable. It is not deliverable if it has no documentation when documentation was necessary. Documentation is not always necessary, right? Constant contact integration. Put your email address in and it goes to constant contact. Probably doesn't need that, right? But if there's something custom or something specifically to fit a certain workflow, just enough documentation. Now the question would be who writes that? And I think that that would vary from team to team. I would tend to lean on the developer doing that, but the Zurich team, for example, has a user experience person who's very, very, very talented. Does all of the testing and usability and figuring out whether this really works the way that it needs to work for the user? So she is likely the right person to also at least engage in documentation. So I don't have an answer for that except to say that it must exist and it must be correct and that it's not launchable unless this document exists. Does anyone have any questions about development documents during the process? Isn't it funny? That's the easy part. Once you start building things, then it gets easier. Yeah, who is it? Uh-huh, someone? Yes. They are not the same thing. So, well, yes they are and no they're not. I'm actually, and that's a good question because I'm using them to mean two different things. When I say a feature, I mean a group of functionality that actually delivers a new experience on the site. So that can be a little thing like the enter your email box and that can be a big thing like a forum. That's one way that I mean feature and that's how I mean it here, right? But in user stories, in user stories, they are supposed to be deliverable, thin vertical slices of deliverable code. And so that's not necessarily the level of where I would engage in documentation. It is very anti-scrum and Scrum Master would be throwing things at me for saying that documentation for each individual user story would have to fit the definition of done. But my experience is the place where you engage with helping people how to know what they're using, right, with their feature, doesn't necessarily happen at the level of user stories. So the right answer is yes, every user story should include documentation in order to make it deliverable or it's not done. My experience tells me it's not that simple. So what it is really in the way you're talking about is the difference between a user story and an Epic, right? What I'm talking about is from more the technical backend, right? So I'm not thinking right now so much in terms of user stories. User stories, like for example, I could build a branch and have 10 user stories that contribute to building something that then is going to launch in one piece. That's not a Scrum way to do it though, so now I will make this too complex an answer to the question. In other words, the right way and the experience way are not the same. But yes, a user story can be one thing or it can be contributing to building a larger feature from a technical point of view or from a user point of view, right? So for example, forums. There isn't going to be one user story that says build a forum, right? There isn't, there's gonna be many. Each one of those should be deliverable and should be able to launch in the forum, right? Each one of them should be, but where I'm talking about this is that when the forum is ready to launch, make sure that people know how to use it, right? Okay. Okay, and the last thing, and this is my favorite thing, right? Handwritten thank you notes. Handwritten, not handwritten thank you notes. That once there's been engagement in relationship and engagement in documentation, you've given people everything that they need. In my opinion, the very last thing that often then leads to the next first thing is take the time to write by hand on stationary of choice, a thank you note. Because, and along the way, if someone contributes to a project, send them a note. If you are engaging in the proposal phase and it's not a project you win, send them thank you notes. Handwritten thank you notes to the people who were considering you. I like to do this also once a year. I always promise to do it around the holidays and I never do because I'm too busy. But handwritten notes, I think, are one of the most important documentations and then the thing that no one ever talks about. So thank you for staying, even though your speaker was sick. And thank you for allowing me to use the $100,000 investment I made in a theater degree and then never used it. Thank you for making me feel better and for my stepfather to feel better about all that money that I did not end up now using. So improv training. So thank you very much and enjoy the rest of your day. Thank you.