Procept - The Role of the Agile BA

good evening everyone thank you for coming my name is Ollie shibi and I want to talk tonight about the role of the agile BA the agile BA is a role that many agile practitioners don't believe has to take place and I will talk about the importance of this role a couple of ground rules for the session first of all let's treat this room as the Vegas room whatever happens here stays here it means that no question is a bad question and by the way if you came to rest here it's the wrong place couple of goals for the session essentially apart from being a part of the agile be a certificate from the IP ma we're also going to talk about effective and efficient way to have the BA performing walk that adds value in agile project environments the main objectives here are to take a look at the role of the BA throughout the lifecycle sometimes helping with the testing sometimes helping with user stories and requirements and sometimes being the eyes and ears of the project sponsor or the product owner the structure we're going to start with a little bit of an introduction about what agile methodologies or approach and then we're going to take a look at the role of the BH were planning through iteration 0 helping articulate stories helping articulate what is done and a few highlights so first of all let's take a look at what agile approach is the agile approach is made out of multiple methodologies and they do is that unlike waterfall where we do things and then we move to the next thing so we design and we plan and then we code or build and then we test and then at the end we produce something with a big bang all the big effort in the planning translates to big effort in changing those plans and requirements as more things come to life agile of course comes to answer some of these challenges and provide us with in a terra team an incremental approach where we plan a little we do a little we learn a little and then we refine what we've done and build upon the previous increment of what we did some things that happen at the beginning of the agile project include great clear vision it includes also coarse grain and requirements and coarse grain planning core strength means rough as much as we know without the need to go into details because as we move ahead more information will come to light and as this information comes to light we are going to be able to improve our requirements our planning and of course our performance so it's not that agile methodology is a set of waterfall projects but in a way every time it's a mini project where we build something we create it it's a production quality product and then when we finish we move ahead from where we are plan the next iteration or the next sprint on top of the previous one and then take this next increment and put it on on top of the previous one there are a few principles in the agile approach that the BA is really suitable to help yes we all talk about the need for a technically excellent and self-directed team but at the same time we must take into consideration but not all team are completely cohesive there are many moving parts fast moving parts in an agile approach the organization is not always suitable for such methodology or such approach and that's why we need the BA to cover some of these corners and sometimes make up for some deficiencies with the team talking about visibility talking about a productivity talking about delivery of value to the customer and of course managing with that agile even though it doesn't do anything specific about risk management it actually reduces the planning cycles making it smaller packages that are easier to plan for and by that containing the risks when we look at a Giles we have the product owner equivalent to the sponsor in non agile environments the project manager in an an agile environment it is of course the coach or the scrum master and we have the team the technical members of the team there is one wall that is conspicuously missing here and it's the agile ba the agile business analyst there's just no or very limited mention of this role and as we see the agile ba can help the scrum master or the project manager definitely can help the team members whether it's in creating stories or in testing and the BA can and should be the eyes of the in the ears of the product owner of the sponsor almost like a proxy sponsors sponsor if you like somebody on the ground that can help the sponsor considering that that product owner may be quite senior in the organization and will not have the time of day to provide the edge our team as they need it the main change in the roles is that the BA becomes a storyteller and the BA becomes an entity almost that covers for all sorts of variations in performance of the team the BA also as usual owns the product side the requirement side and the eyes and the ears of the product owner considering the increasing roles of testing in agile environments we also need the BA to help with writing test cases and sometimes even help execute tests in certain circumstances of course the wall of the be a traditional not traditional remains the same here we are looking at really interpersonal skills elicitation we have attention to detail but we have also Enterprise analysis and I add this kind of skills listen to the subject matter expert help team members pick up stories based on their skills and experiences and then in the agile environment that transformation in the way that we do business the transformation that we have in the we write code we need the facilitation skills we need those leadership skills we need those interpersonal skills to come in and help address the moving parts of the agile project when we look at requirements we all know what a requirement is a requirement represents a need is something that has to be done by the project in non agile approaches typically Waterfall we tend to finalize the requirements early on and then when we move on and the needs change and the realization changes we probably need to change those requirements at great cost and during great risk the I couple of assumptions also when we talk about requirements one of them is that we're looking at what used to be requirements gathering there was an assumption that the customer knows what they want knows what they need and we are just gathering it we are just asking them and then came the realization that it's not about requirements gathering it's about requirements elicitation because we cannot assume that the customer actually knows what they want we need to engage the customer we need to get them to realize what they want and then we will document it so we have the customer who we assume knows what they want and the other assumption is that is that the requirements are not going to change we are so busy baselining them and finalizing them that there might be a situation that when they change if they change and most likely they will change we're going to find ourselves with a big change control process that is heavy expensive and of course risky agile requirements are different we recognize the fact that change will take place we recognize the fact that the customer is not completely set about what they need it doesn't even realize exactly what in it so we are creating user stories the user stories are what will become the requirement it starts at the higher level and it will represent at the high level of detail what the customer needs and then as more information comes to light as we realize things we will refine that user story until it becomes a full scale requirement that a developer in the tester and anybody else for the technical team can take and walk with a user story has essentially three parts the first part talks about the user as a as a user the second part talks about the functionality or the need so as a user I want to or I need to do something and the third part talks about so that as a user I can do something so this is what the business value comes in this is where the benefits are realized for example as a dog I would like to order food online so that I do not rely on my human right so here we have the three parts which helps us in the traceability process and not only in articulating that requirement as we refine things we're going to write down in the back of the card the fur the information that we need we may support it with use cases that I'm not going to discuss this evening in order to visualize what happens and at that point the technical team is going to be able to pick up that requirement and walk and develop and build something according to the needs that the requirement represents developing the user stories usually is the role of the team sometimes we need a BA a business analyst that has an understanding of the business needs has some understanding of the product and serves as the traditional bridge that the BA serves help the team members articulate help sometimes almost playing devil's advocate asking some questions challenging making sure that the story is written in a way that will be clear to whoever is going to develop it bill wake at the time said that we gotta invest in a good story and invest the letters invest of the word invest represent the acronym of what we need to look for in a good story I for independent the story needs to be independent and for negotiable so it's not a final story and it may change as we move ahead we for valuable it adds value to the user or to the customer if for estimable so the customer was going to do the walk he's gonna have the ability to estimate based on the story asks for small just like in the WBS we're gonna have a small storage small enough so it can fit into one iteration however shot it maybe even a week and t4 testable so we know what the acceptance criteria of this story so we don't have a situation that we're building something and we don't know how to determine whether it's good or not stories can be big and they don't necessarily have to fit into one iteration moreso than not we see many stories that do not fit into one iteration we're going to call them epics and epic is a larger story again the BA will be able to help tracking the progress in the epic and larger story that doesn't fit into one iteration and then it's gonna fit into two or three just like a lot of the wings every book or every movie is a standalone but together they make full sense large toys can also be themes these are stories that will be elaborated later on in order to become smaller stories and as themes they will represent what an iteration a future iteration will do so we have the tasks the team members will write the stories will articulate will refine and the BA will be there to help them and to facilitate the process and to make sure that we know when the story is a good story many agile practitioners also talk about the fact that they do not like iteration zero and once again I would like to beg to differ and say iteration zero is very important it's much more common than many like to admit this is an iteration to prepare to help articulate acceptance criteria to help refine stories to build databases or any any type of infrastructure and once again with this type of general or non direct value add jobs the BA is a very important role to help in the process when I say no and walk it means that whatever we do in iteration zero is not going to be in the sense of creating product value direct features and functionalities for example but it's going to be of value for future iterations that we're going to be able to use what we do in iterations you the role of the beer of course in iterations you help articulate success criterion acceptance criteria help refine do documentation look at changes go back and forth sometimes serve as the eyes and the ears almost like a proxy product owner when I say poor proxy dot product owner I don't mean that the BA makes decisions on behalf of the product owner but the BA can be there to make decisions within the mandate that was provided by the product owner when looking at managing backlogs or the backlog the BA also has a very important world in many environments we use more than one backlog we have the backlog of the stories that have been estimated and prioritized and then we have two other backlogs the secondary backlogs or the shadow backlog this is the backlog for new stories that are being created they have not been estimated yet they have not been prioritized yet but they're there and the BA is typically the manager of course of this backlog and then we have the defect backlog once again when defects are being produced and they're not making it straight into the main backlog we're going to put in a secondary battle this will also help us label when we talk about a defect and when we talk about a new story or and you need of course when we talk about creating the first backlog it's almost like not an experimental but there will be some variations and here we even have the BA to help articulate how it's going to be to manage that of course to help represent the values and their priorities that we need and to record our performance and make sure that we learn from what happened in the first iteration backlog management yes the owner ultimately it's the product owner but once again we're going to have the BA on the ground especially when we have product owners in to organizations that adjust not available to be there on a regular basis of course for prioritization we have three four levels of prioritization we have the business prioritization that is done by the product owner we have after that technical considerations typically by the technical team then we have minimal functionality set that is product on and the technical team together and eventually we have story dependencies which are done by the technical team in each and every one of these stages the BA is a very important factor in helping articulate the back and forth and help those roles articulate and prioritize the bathroom there's another element in agile that is very important to understand and it's a story of what is considered done done when I tell it it it's done I want to be able to realize that we are all on the same page in waterfall done means that I wrote the code and I tested it and I hope that it works I'm exaggerating a little bit but in agile dam means that it's not only built the way I want it's not only conformity requirements it also fits for use it means that whatever I've created is doing what it's supposed to do to the extent that it's supposed to do so if I build a whole stable done means that people and horses are coming in and out and using the horse table as intended as opposed to I have a building I have the requirements I have the people standing outside and somebody doesn't have the key for example that's pretty much it we have here at least for discussion of a whole bunch of ba characteristics and trades and walls and responsibilities these are not much different than the role of a good ba in a non agile environment the difference here here is is that the BA is almost like a beer on steroids stuff is moving fast prioritization is taking place priorities are changing stakeholders are changing needs are changing all the change happens in real time yes in agile we do not do change while we build the product we stop in between the iteration we do change of course we have the role of the BA in the retrospective in the iteration review in the demos taking notes taking records of what's happening making sure that lessons are being applied making sure that we take a look at the lessons that are being applied to check that they're being applied properly or that they had add value and really in summary the BA really carries a set of four hats on top of the BA one of them is the eyes and the ears of the product owner and the other one is a storyteller making sure that the stories are in line with what we need to the extent invest a good story we have also the BA as a leader and as an innovator in an environment that constantly changes in environment that claims that it adapts to change the BA is at the forefront of this adaptation to change at this point I would just like to get you to remind you that what we talk about here is not only to take away and think about it we also have to think about so what and then to think about now what what are we going to do with that what is going to be the action plan as a result so thank you very much of course these are my books and I would like to thank you all for coming here have a good night you

Channel: Procept Associates Ltd

Views: 14,748

Rating: 4.909091 out of 5

Keywords: Procept, IIBA, CBAP, PMI-PBA, Business Analyst, Agile, Agile BA, Schibi

Id: fZBYzXUn5uo

Length: 19min 50sec (1190 seconds)

Published: Wed May 04 2016