IIBA Spotlight Series: The Agile Business Analyst Margaret Dessypris Thomas, CapTech Tuesday, Sept. 10, 2013 Public Webinar

Transcription

1 IIBA Spotlight Series: The Agile Business Analyst Margaret Dessypris Thomas, CapTech Tuesday, Sept. 10, 2013 Public Webinar Mauren: Hello, everyone. It s September 10 th, and time for the Agile Business Analyst presentation by Margaret Dessypris Thomas, presented by the International Institute for Business Analysis. I hope everyone s well today. I am your host, Maureen McVeigh. I ve been a Business Analyst for many years, including being part of the business side of information technology. Not a technocrat, but working on the business side and a founding member of IIBA. This isn t about me. This is about IIBA being an international, not for profit association for the practice of business analysis. We have two certifications Certified Business Analyst Professional and a Certified Competent BA. As well, we have a number of projects in the works, not the least of which is version three of our Body of Knowledge, which will be released sometime next year. Of course, our latest member benefit, which is the Agile extension to the BABOK Guide. I really like this document. It really explains how various roles of a business analyst work within Agile. One of the quotes from it is that everyone on an Agile project does analysis. I really like the fact that we don t necessarily have to have the title of business analyst to be doing business analysis work. Today s session, a really quick introduction so we can get into the meat of the presentation. Then, throughout the presentation Margaret is going to be taking questions, as well as at the end. The idea for today, and we hope you walk away with some information about what the differences are in the different styles of Agile, why are blended roles so important in an Agile project, and how the knowledge areas are applied in an Agile project. This is great stuff. I m really looking forward to this information, and I m really looking forward to having Margaret talk about her experience and her background as it relates to Agile. She has 12 years of experience in the healthcare industry in both business intelligence, service oriented 1 International Institute of Business Analysis

2 architecture, and operations management. She s very much about process improvement and organizational change. She has a BS in Information Technology and an MS in Information Systems, as well as her CBAP certification. Welcome, Margaret, and thanks for joining us today. Margaret: Thank you very much for having me. Maureen: If you want to ask questions, there is the question box and please feel free to type them in. I ll be monitoring them and waiting for Margaret to take a break to take your questions. Without further ado, it s Margaret from CapTech talking about Agile. We re on the Agile Analyst slide. Take it away, Margaret. Margaret: Today I m going to talk about the variety in Agile implementation. This would be the different styles of Agile because I believe that everybody adapts Agile to their organization and what works for them. There is that purist approach, and we ll talk about that, and we ll talk about some of those different styles. I m also going to cover three distinct approaches to the BA role in terms of, in my experience, what I ve seen who is doing the business analysis activities, and then where in the Agile process do these practices take place. It conforms with the Agile extension. I remember as I started down my own journey into an Agile practitioner, and I was always comparing where the analysis activities or the planning activities are taking place comparatively between a Waterfall methodology and an Agile methodology. I m always intrigued to understand the differences so that you can bridge that gap in your understanding and know how it s different and why it s different. The variety in projects, and I have several of my own terms here. I tried to lay it out in a quadrant format. There s that Waterfall and maybe some of the iterative approaches, as opposed to the pure Agile textbook, classic style approach, which there are very few organizations that are really pure in their approach. There s always some sort of gradient. In addition, there is a Kanban process oriented approach, where Kanban is one of those Japanese terms that relates to being able to queue up the amount of work units that can be handled within a given process at any time versus a more iterative approach of those projects that maybe working on a variety of phases at one time. 2

3 My take and my view on it, I ve laid out different approaches here. Scrum, to the far right, is that pure Agile purist approach. The Kanban work teams, those are the two that I m more than likely to concentrate throughout this presentation. There is also Scrum, but. We re doing Scrum, but we have this aspect of Waterfall that we still adhere to. Scrum, but means you re doing part of the Scrum processes, you re inheriting some of those ceremonies, but when you report upwards to management in the organization, there s still that one way of looking at all projects. I believe that Agile projects do need to be viewed differently when management is gauging the value and the progress and the budgets of those. The iterative approaches can be either more Agile or more Waterfall. There s a lot of leeway that those can cross. There s one term that cohorts of mine and I have come up with of practical Agile, where you are running stories, you are going through sprint and iterations, but maybe you re not getting to working code at the end of every single sprint and things are more staggered. That s why I put it more in the iterative approach because you have a lot more of those Agile/Scrum processes, but it s not that purist approach, but it s not heavy on the Waterfall because the organization also understands some of the differences at a managerial level. BRUF, if you re wondering what that means, it s Big Requirements Up Front. It s those 50 page, 70 page, however many page requirements documents that I m sure many of us have produced. It s where we have done the requirements all up front and have then worked with our technical analysts, so our developers to really start getting into the design overall. Those are the mile wide range on Agile that I ve seen at different clients and talking with different associates and in my own experience in those different implementations. There s always analysis happening in all of these projects. That s pretty critical. If we can quickly concentrate on what the Scrum process is, I m going to make some of the assumptions that folks do know about Scrum and Agile. I do want to talk about who the analysts are, but briefly let s quickly review what the Scrum process is. This is not meant to be an Agile 101 review, but just a quick, five minute refresher. [reference point 0:10:00] 3

4 Our product backlog is developed by a product owner. This lists the features that a product or a software will have. That product owner is responsible for collecting that input from a variety of stakeholders. The product owner brings those stories and the items on the product backlog to the team. The product owner, the Scrum master, the team, it is all one team. They will begin the planning for a given sprint. There s also relief planning in addition to sprint planning, where you develop maybe the roadmap of what high level features from the product backlog are going to be in the next release. That release is broken down into multiple sprints, where each sprint has a further breakdown in planning to come up with the items that the team commits to within that sprint backlog. The tasks are broken down further for each story within that backlog. There is negotiation between the team and the product owner about what that final commitment will be, and that is the result of the sprint planning itself. The sprint then is the one to four week long iteration where the work is done on the stories. There are no changes to the stories and what the story contains. The scope should be static for the sprint. If there is a stop put on a story, there should be a really good reason. If there s a stop put to the sprint, it should be a very, very rare occurrence. Meanwhile, the Scrum master is helping to guide the ceremony, to coach the team to being very productive. The product owner is giving insight, answering questions. They are continually refining the product backlog. Every day we have the daily Scrum, where the product owner, the Scrum master, and the team members all meet and plan their activities for the day. At the end of a sprint, eureka, we have working code. We now review that and it is the potentially shippable product. We say potentially because you may not necessarily release into production at the end of every sprint. That s why we have the release planning, where the release will be the culmination of everything that s been worked on of three, four, however many sprints go into that release. We demonstrate to the stakeholders. Sometimes that demonstration is just to the product owner. Sometimes it is to a variety of stakeholders within the organization or even external to the organization. That s where the signoff and approval about the product functionality comes into play and is obtained. Finally, the team will meet as a retrospective and they will inspect and adapt their processes, their artifacts, their team norms and how they 4

5 operate as a unit. They will take those lessons learned into the next sprint, and then we start all over again. The product owner has that priority of features and that goes into the next sprint planning meeting. Does anybody have any questions about Scrum at a high level? Maureen: I don t have anything right this second. Margaret: Okay, good. Maureen: No problem, that s awesome. One second. Could Margaret explain why iterative and Kanban are at the opposite axis? Margaret: I want to say that iterative implies not that they re necessarily opposite, it was more of just the working styles. Iterative is that project of everything goes through analysis, design, construction. Iterative projects may actually have an item that goes repeatedly through an iteration, either to build upon that functionality. Whereas I see Kanban as a slightly different take on getting work items done, and it has to do with the nature of the team. I will go into that in a couple of slides. Maureen: Well said, It s not really that they re opposite, because a lot of times I believe that all of this Kanban, iterative, Agile, can all work together. It s more about the genius of the ands instead of the tyranny of the or, to quote a book. It s not necessarily meant to be an opposite, but just different. Margaret: Hopefully I m going to really answer your question in a moment, in a couple more slides. Maureen: Excellent. That s a great question. Thanks, Ronald. I have a feeling from Pat, he s asking, Where does the BA fit in the whole process? I have a feeling you re going to get to that, right? Margaret: That s the next slide. Maureen: Okay. One other question very quickly. Gary asks, When is user acceptance testing done prior to implementation? Or is it done during the sprint? Margaret: It s done during the sprint. Maureen: Thank you. Excellent. 5

6 Margaret: It should be In purist Agile, it should be done during the sprint. In those iterative, again, it can be stacked and it won t be in the first sprint or the second sprint, but it might be in the fifth or the sixth or the fourteenth or the fifteenth, based on how many sprints you re going. Again, the difference is between iterative and the purist approach. Who are the analysts? This is where my circles are showing up. The question about where does the analysis or who s doing the analysis and where is this taking place? The product owner certainly has a good amount of analysis on his or her plate. They should understand not just their industry. They need to understand the demands of their stakeholders, who all their stakeholders are, the functionality. They have the great vision for a particular product. There s a lot of analysis, whether they realize it or not, that should be taking place. A lot of Agile teams who have issues with their product owners may be based on the fact that their product owner doesn t have a strong analytical background or an understanding that they are to be performing some of those analysis tasks. Additionally, the whole team may have responsibilities to perform analysis. Like it was said earlier, everybody has some responsibility for analysis. I couldn t agree more with that. There are, as we know, a variety of either the business analysis, the technical analysis, the solution definition, all of that is going on. Definitely the team has that responsibility. In some cases, we see where we have a product owner working with one or two analysts on the team that the rest of the team is maybe developers. If you re really lucky, a QA, quality assurance testing role is also on the team. You only usually have five, seven, at most nine people in a Scrum team, ideally. I have seen stand ups that have 15 and 20 people in them. It doesn t work very well. People do try to expand the bounds. If you re working in that ideal setting of seven plus or minus two, you may have one or two people who are truly that analyst role. They will be working very closely with the product owner and will almost serve as a proxy to the team for them, especially if the product owner is not able to always be around. Ideally, product owners should be involved with the teams at least 75% to 90%. Some of you may smile and giggle because in your Agile experience you might have seen the product owner 10% of the time, 6

7 20% of the time. That s where an analyst on the team is critical to helping to convey the message of the product owner. Those are the roles that take up those analysis efforts. That s who s responsible for doing it. [reference point 0:20:00] If we could go into the next slide, which talks to some of the Kanban aspects. We have a backlog, and this is a sample Kanban board. We have that backlog of requests. We have our current to do, which represents the sprint backlogs potentially, or the analysis activities that may be taking place on that to do list. The designing, developing, testing. Where Kanban looks at the actual phases and steps within a work team. It s not always to do designing, developing, testing. Based on the type of project that you have, you may have different phases. You want to gear that top level of phases to how things work for your project. You may want to do a breakdown of testing where it s unit testing, integration testing, UAT. You may want to be that specific for your Kanban board. As you progress on a story and it moves from one column to the next, we are also careful to note that it can t move until there is space in the next column to accept that story work. Only four items can be in the to-do column at one time. Only four stories can be in the designing column. Only three stories can be in the developing column, and only two can be in the testing. We see where our limitations are and our bottlenecks are as a team, if that is one comprehensive team that is moving forward with a project. There is also the Kanban approach that you may have a team like a production support team, a DBA team, a team that gets smaller individual work requests that is supporting hundreds of projects across an organization. Kanban can work really well for those types of teams. I ve also seen the situation where, if we go to the next slide, there is an analysis team of several people. There s team A and team B. They are working through their stories and they are doing their research, documenting requirements, communicating their requirements, doing a walk through, and then they consider themselves to be done with that story and it s handed off to the next team. Due to the formatting here, we re not seeing those three boxes in the middle, but that is in fact the development team one, development team two, development team three. There might be two analysis teams feeding three development teams, that is then ultimately feeding one 7

8 testing team. I don t know why testing gets such the short end of the stick in projects. If we look at maybe a program of work that is going on, there may be multiple efforts or multiple components that all have to be developed. We re still looking at it closer to a Waterfall approach than an Agile one or a true Scrum methodology because we re still looking at analysis, design, development. More in this setting, it seems like there s a separation of the analysis from the development from the testing. We know that in practice, we have much better results when we converse across all of these roles on a team. The results and the quality of conversation that can get to what you re really looking for out of a software project, in my opinion, tends to be a lot better and much more efficient. In some cases, with large products and programs, they will set up teams in this fashion. In this case, there s not so much a product owner rolled out. There may be the project sponsor and the executive sponsor, and the deliverables are produced out of each team and they feel like they re thrown over the wall. There s less interaction. When we look at the Agile manifesto, we know that team interaction is valued more highly than the process itself or the contract or whatever. We want that interaction to get through the project and to get to the final work product. That s kind of some of the extreme views of Kanban that I ve seen. They re using that Kanban board. When we compare it to a Scrum board, and if we could actually go back a slide, the Scrum board looks more at not started, in progress, and done. The tasks associated with the story are what are moving across three columns and only three columns. It should be everything, from some of that analysis to design to development to testing to UAT. All of that should be happening within our more purist approach. Our Scrum board looks different than what the Kanban board looks like. If we could now advance two slides forward, to our three views on the BA role. Just to reiterate again, my experience has seen these three approaches where the business analyst is the product owner. They are one and the same. They have that ownership; they work with the developers in that role. Usually the product owner, though, isn t so responsible for producing heavy amounts of documentation. Agile is lighter on the documentation, normally. It doesn t mean there s an absence of documentation, far from it, because we need that as a communication vehicle. The documentation 8

9 is not done up front as much as it is at the end of a sprint or at the end of a release to produce a document what it is you have done as opposed to what you are going to do. The next one is the analyst team. This Kanban approach where the whole analyst team looks at the stories and coming up with more of the requirements before handing the story off to a development team or a testing team. We ll come up with all of the acceptance criteria and maybe more of the test conditions that are associated with a particular story. They may have more detail and background within that story document, per se. The analyst team member is that proxy role where the BA serves the product owner and is dedicated to that team and dedicated to that product owner, but that product owner may have more of the outward facing responsibilities to the organization or to the external customers and will need that BA to rely on. That BA will work very closely with that product owner. A lot of times when that BA role is established as proxy, that individual will perform the quality assurance role and the testing role. Some of that borders on solution verification and validation, and they re looking at not just doing the integration testing with the developers, but as the story nears completion they will begin to work directly with that product owner and say, Hey, I want to show you this. I want to get your take on it. Even before the demonstration happens, putting it in front of the product owner should be taking place. It doesn t always get the chance to, but if it is possible to put that product in front of the product owner to get their input and their take on it, We have this, we have these questions for you. We wanted to get your input and feedback. Do you think this is really going to work? Those questions are going to be asked by that BA team member to get that information from the product owner, and then relay that to the team. A lot of times the team is located in one room and the product owner may be away. [reference point 0:30:00] I m not going to go into the issues of virtualization with Agile teams because that s a whole other presentation. That BA helps facilitate that conversation and serves as that proxy role. 9

10 However, when the PO really accepts the responsibility for forming that BA role in that first column, I feel like a team is much more likely to succeed with Agile, and even not so much Agile. When any time there is that executive sponsorship and you have that strength and visibility into a project within an organization, that s one reason projects succeed. Regardless of what methodology you re using, we always need that sponsorship. Having that direct PO involvement helps significantly. Regardless of are you the PO, are you just the developer that has to perform some level of analysis, or are you truly the business analyst title on your signature, either way in any of those situations, good stories always require decomposition. Somebody can come up with this requirement that is huge. Say it s bigger than a bread box, it s so big I can think of a multitude of ways this breaks down. The product owner or the analyst should be doing that decomposition. There are different ways stories can break down. This matters not just to the product owner in relaying out to external stakeholders and internal stakeholders to an organization how functionality will progress and how we will see a product be developed, but also to the technical team who has to build this functionality out. What dependencies within the code exist? What pieces need to be built first? What pieces are similar and can be repeatable? We know that as we develop code, there is this ideal of a code library that can be reused over and over. We have similarities in functionality where a multitude of ethics may exist, but all of them have, I want to view a list. I want to select an item from a list. I want to edit an item on the list. I want to delete an item from the list. The more lists you have within your product, you know that your delete function may be somewhat similar. You re listing, you re editing based on what the nature of those actual items are. Each one is going to have specifics, you would hope, but there are some aspects of repeatability that are going to exist. We can begin to list stories and know that all the views may be estimated at about the same level of effort, the deletes may be estimated differently. Creating a new one may be all over the map based on what a new item really means for functionality. With other ethics, we have group A and group B. An example of this is we have a tool where somebody can log in and submit an application for some sort of benefit or service. The other group, I think group A is where the administrator can go in and see all the applications that are listed. 10

11 In order to build out one, it s dependent on the functionality from the other. The functionality for one user group or one persona type may be in group A, whereas the other personas that may exist may be group B, group C, where they all have different layers of functionality. If you have hierarchical user roles, they may also be different groups. Each one of them have different functionalities. As a manager, I should be able to log into the HR system and view my direct reports. As a direct report, I should be able to log into the HR system and view how much my biweekly paycheck is. There are different stories that are out there that matter that can be divided into groups. The last view I have on this is looking at the dependencies; that we have to build our capability to be an employee before we necessarily build out a manager looking at the employees. There s that dependency of these stories that really makes more of a difference to the technical folks in what order they re going to build from. Understanding this mind map of stories can be very instrumental in that negotiation process with the analysts, technical folks, and the product owner to know what does our road map really look like and how is this product going to progress? Any questions at this point? Does that answer the question that was out there? Maureen: I think it does to some degree. There are a lot of questions about levels of information. I think the lightweight documentation is being perceived as something that is not testable or doesn t include nonfunctional requirements and things like that. Could you elaborate on how those are documented within user stories? Margaret: The user story template that I use is for a given story when it is in the most decomposed place that it can be, the most atomic sort of structure. It has this story format. As a user, I want to do something so that I can achieve some result or objective. That s at the beginning. The next section of the template goes into the acceptance criteria. I must be able to see a list of my employees, I must be able to select something. Whatever the functionality is, our acceptance criteria associated with that particular story. In order for me as a product owner to say that this story is done and accept it as working code at the end of the sprint and for the team to understand what it is to get to done, those acceptance criteria are key. The next piece that may be within that template or broken out separately is the test conditions. I have a prerequisite, an event, and a 11

12 result. I will have a multitude of test conditions that can be prolific for one particular story, even though it s a small little story. To give a healthcare example, if I have a diagnosis code that I want to enter into a tool, it has to follow a particular format which means it s a five digit field that will or will not have the decimal, and if it s an incorrect diagnosis code I should see it flash in red. When I enter in a diagnosis code, I should see this type of result or I should see something else happen in the next box based on the processing that s happening with the system I m thinking of here. All of these test conditions should get laid out. The unique thing about the business analyst taking the time to lay out what these test conditions are and working with that product owner, is a lot more times it elicits the very detailed requirements that aren t present in the user story format. We could talk about functionality as, As a user, I want to do this so that I can achieve this. That still feels very light. That s too lightweight for a lot of analysts. You want to get down into the meat and the substance of what s there. Those test conditions that come out in order to help define what does or doesn t have to take place can help supplement some of that lightweight piece. There is other documentation, so lots of other technical component diagrams or state diagrams, personas. How many different business rule documents have I written and whatnot? Sometimes those are created as you go, and I think I talk about this later on in the presentation. A lot of this information, your data model, your relationships and what you re working on at any one given time, that all should be a collection of documentation that is collected and stored in some way. [reference point 0:40:00] That talks to our requirements management and communication processes and how we re capturing the information about our product and our projects. They may be things that are up on the wall or on a white board and you have a way of tagging a picture and archiving it in a shared folder some way. Whatever works for you. The documentation is created as a result of the conversation. Say, Okay, now we re going to do this. I m going to go back, and now we re going to test it. This is what you developed. I m testing it based on what we agreed about, and there it is. It s working. 12

13 Then you document out of that at the end of the sprint to say, These were the requirements that fulfilled and this is some of the technical basis behind it The idea is that we re lightweight with our documentation up front, but that s to say that we don t have documentation at the end of a project. That can be as much of a Waterfall project. We know that the documentation we ve produced at the end of an Agile project is always going to be valuable, at least to the next development team that may have to pick up and work with that code base. To start talking about how the different knowledge areas relate in [inaudible 0:41:55] activities, when we talk about enterprise [inaudible], always know that as we initiate a project or even to get to the initiation of the project in certain organizations, we have to have made that business case. We have to have developed the business need and defined the capabilities that are required before a project actually takes off. That product vision really is that business case, business need, and capability definition for what is going to take place. This picture right here actually talks to the cycle of product backlog grooming that a product owner is responsible for doing. In our most purist forms of Agile, the product backlog is not static at the beginning, nor will it remain static throughout a project. It does evolve, and as we release code and we are able to give it to the users, they give us feedback about what they liked or what they don t like or what they wish they had. Sometimes they come up with a new requirement the product owner never even really thought about. All of a sudden, Hey, you know what? That s my new priority for this next sprint, and that s what we re going to work on. This is what we re hearing loud and clear from our user base, so that that team to include the product owner will look at that feedback and say, Okay, if this is the next story, this is what it s going to take to do that. It s in the backlog and then they work on it and they implement it, and then they get more feedback. We get to the point, however, where we fulfill the vision, we ve met the capability need, and therefore we can actually begin to close out the project that for the investment that we ve made, we are getting what we need and now the project can shut down. It is that continual product backlog grooming that takes place to know that we re meeting the right valuable goals for a particular product. 13

14 We do have to put scope around that project, as well. Some of the scope modeling that takes place, we have to know when we venture outside of that scope. That s not within the scope of this project. Maybe that triggers a new project or phase two of a project, but we certainly as a project it has a beginning and an end, so we know that those scope models that an analyst can help deliver or should be delivering will be critical to [inaudible 0:44:58] the project. The PO is responsible for that elicitation of the end users within the organization, and even external. The process of getting the solution in front of the users and validating that it s meeting our business objectives is giving us an idea about that solution performance. Our enterprise analysis also can happen within the sprint to know that our solution approach is correct. I think one thing where I differ with the Agile Extension of the BABOK is that Agile isn t necessarily the solution approach. I think of a solution approach is how you re going to solve the problem in terms of the architecture, the processes. When you re working with a team, you should be having those types of questions. You get into the meat of that during the sprint itself. The solution scope as part of enterprise analysis will also be how about a product owner and the team is part of that backlog definition, whether it be the product backlog or the sprint backlog. Some of that scope containment is done by the team members at the beginning of the product backlog definition and throughout that iterative process, and then the sprint planning itself. The whole idea of prioritizing the product backlog, we know that part of our requirements management is to prioritize the work and felicitating and getting items on the backlog is the product owner s responsibility. Organizing them and putting them in an order that makes sense or knowing how we relate to one another, if the team does. Have those conversations during the sprint planning to know what sort of dependencies are out there. Defining our assumptions and concerns are always critical as part of that sprint planning, as well, because you may say, We can t work on a story. There are too many assumptions we re making about something. We need those assumptions answered. It s a way of pushing back on the product owner and saying, We re not ready to work on this story. This story is not ready to go through a sprint. 14

15 You can certainly use that as a team member to say that there s not enough definition here that we feel comfortable working on this, unless that product owner can help answer those assumptions. The task breakdown that happens within sprint planning allows us to look at planning the BA activities and what type of requirements management we may use. The estimation, more of that functional, technical decomposition. Coming up with more questions about the content of a particular story. You may push back on a product owner again. We need a survey to collect feedback about a particular item. We may need to do some modeling associated with this to give the information to the technical folks. Data or process modeling may be critical as part of those BA activities. The communication comes out at the end of sprint planning where the product owner will relay back to the organization, These are the stories being worked on by this team, and they will be complete in two weeks. When you get into a cadence with your team, you have the ability to reliably say what stories you ll complete at the end of a sprint. [reference point 0:50:00] Our stakeholder analysis, I believe we ve said that the product owner is going to do that, but the team will break that down as well in the sprint planning to update their documentation about the personas and actors involved. In the retrospective, the retrospective allows us to look at our business analysis approach, the communication, our management of things. We have that inspect and adapt in many different aspects, but just as much on the analysis taking place to be successful with these stories. We can forward also to our sprint review. We have verification of requirements within the team, by the team as we are testing and making sure that we ve coded things as designed. Also, the validation of the solution to know that it s meeting our business objectives is putting it in front of the customers, in that immediate and continued use of the tool. If we keep going forward to the next slide, let s talk about management and communication. We always have these scope questions. What is our minimal viable product? That s a huge discussion point with product owners and their management, to know what s going to be within releases, what s going to be within sprints, and communicating out those commitments. I think I ve talked to that already. 15

16 Our reusability that stories can be reused for the technical team to understand the functionality and how things decompose. Our communication is continual and ongoing. Every day, at the daily stand up, we talk to what items we re going to be working on and who we need to meet with throughout the day in order to have a communication about the product itself. Traceability is a big thing. We don t have necessarily the exact same sort of traceability. It is equally important when you compare it to a Waterfall project, that maybe you don t have a traceability matrix that states, Here s the business requirements and the multitude of technical requirements and the code elements that have been developed and the test scenarios and test cases and our V model of how documentation feeds into the quality assurance documentation that comes out of a project. We have a story that within that document we know what the acceptance criteria are. We should know what the test conditions are, and if there are other test scenarios that have to be out there that are performance based or those non-functional requirements that we have to test, those may be in a different document and sectioned out. Our traceability happens as we re going through the development of a story. We re concentrating on just that story. We shouldn t miss anything. If we know what done is and our product owner is going to accept that at the end of a sprint, we should have fulfilled everything and everything that we ve done should be traceable back to that one story that we ve worked on the whole time. Traceability happens in a slightly different way. I talk about ethics and themes and trains. That s where we re talking about large programs doing Agile and knowing that ethics will break down into a multitude of stories. Documentation like we said, it s lightweight, but that doesn t mean we can t use a repository. The repositories that are out there, there s version one in Raleigh, which are great for documenting the Agile process and the stories that we re working on, but that s not to say that we don t use a rational tool or quality manager. I ve seen quality manager uses, or blueprint, or there are a number of requirements documentation tools that can be used and you just build on it as you go through a project. As you go through the sprint, you re adding your documentation out there. Just because you re using Agile doesn t mean that if you don t have big requirements up front that you 16

17 can t be using those requirements management tools. You re just adding to it in a slightly different order. Your deliverable is the requirements at the end of the sprint maybe instead of at the beginning of a project. Going on to the next slide, our modeling of requirements. A lot of times we think about our very pretty documentation that s produced as a result of our analysis efforts. This is a high level online tool that allows us to look at inventory, shipping, taxes, a customer. There s some sort of point of sale and inventory management going on here in getting a product out to the customer directly. This might be something that s just on the wall for a long time. All around it, on our white boards, we may produce a variety of different modeling tools that are a result of conversations. With the product owner there, with the technical team members there, you have exactly what you need. You will take that as an analyst and you will either just capture a picture and dump that into a document because the idea is to not spend time on making a document pretty. That s not what s valuable. It s the working code that s valuable. That s not to say that we don t need that documentation. It s fine to just have the conversation on the white board, agree to what s on the white board, and go off, build it, have the product owner come back, it s testing, the UAT happens. Okay, we re done. You may have done that in the space of three, four, five days to get to something that you ve talked about. When you snap your pictures, you put it in your documentation, and you put it out there. You haven t spent a lot of time on the documentation itself. You ve gotten to the working code right away so that when we talk about the type of BA activities, that s exactly how we get those done. We ve elicited by having those conversations right there. We ve managed our requirements and communicated it to the people who needed it right then and there. We ve modeled our requirements. We ve done some more of that requirements analysis by virtue of having these things up on the white board and making sure the whole team is seeing them. They help us to continue to verify those requirements. To kind of look into wrapping this up, I ve pulled a picture from the BABOK 2.0 that kind of summarizes all of our knowledge areas and kind of shows the relation and the interdependencies of these activities. All of these are happening on our project. None of these cannot happen in a project and have that project still be successful, in my opinion. 17

18 Whether it s the BA on the team that s performing the role or the product owner, the team members at a more detailed level, these activities take place. If they don t, I believe a team is limiting their degree of success. I have one more slide after this just to wrap up the Agile analyst overall. Are there any questions that I can help take at this time? Maureen: I think we could probably hit on one question. What I ll do is I will maybe contact you later for the other questions and we can post them onto our LinkedIn site. I guess the question is, Is there an expectation that coding should start on day one? Margaret: No, not always. Maureen: Not always. The idea is that the user stories are developed prior to a sprint? [reference point 1:00:00] Margaret: Yes, stories should at least be developed so you know what the story is and what the acceptance criteria are. Maureen: Right. Margaret: We have the sprint zero concept, which is what it takes to get a team ready to be able to develop. It gives you that leeway so you re not developing on day one, but you can be getting your environment ready and you know that you re going to have certain types of personas. You can being to build the shell of things. Maureen: Excellent. It seems as though it makes sense for there to be a traditional person with the title business analyst work with the product owner. It seems as though that s something that s a necessity in most cases. Margaret: it depends on how involved a product owner is. If you have a product owner that s dedicating 90% of their time, they can certainly be that business analyst role. If that product owner isn t there for the team, then you absolutely need one or two analysts based on how many stories your team is taking on. Maureen: One more very quick question. Can you use use cases instead of user stories? 18

19 Margaret: User stories are good from being able to log the card and moving the card across the Scrum board because you want just one way of identifying it, whereas with use cases you may have a multitude. Actually no, if you decompose correctly, you should have a use case that is discussed within a story and even the exceptions or the alternate paths within a use case may be a separate story. You use whatever documentation fits the way that your team works, because maybe that s the best way to document how a system is supposed to work. There s nothing about Agile that says you can t do something in terms of documentation. You don t want to just do all of your analysis up front because we know that business needs change. Agile is that approach to be on top of the change that comes our way. Maureen: As long as it s within scope. Margaret: Exactly. Maureen: Yeah. You know what, there s never enough time to talk about Agile. There s just so much to discuss, and I really liked the part of your presentation that said, There s no one size fits all. Pure Scrum isn t necessarily what every organization should be using, and rarely is that the case. I really liked the fact that you align this to the fact that BAs, all of our tasks are still necessary for an Agile project. I can t thank you enough, Margaret, for taking the time to share your insight. I d like to thank everyone on the line for joining us. We will address your questions on LinkedIn. Join us again for more information on Agile in the coming months. Thank you so much, Margaret. Margaret: Thank you. Thank you, everyone. Maureen: Have a nice day. 19