tag:blogger.com,1999:blog-57339093936286942152024-03-13T07:01:56.832+05:30Smart Business AnalysisA group of business analysts talk about their role in the custom software industry and their trials and triumphs in providing the quality software to their clients.ShareKhanhttp://www.blogger.com/profile/00144902507217458661noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-5733909393628694215.post-10365799919638794522010-03-30T15:35:00.004+05:302010-03-30T16:25:53.520+05:30Business analyst : Domain expert or Generalist?I know most of the people in our community would have given a thought to this question. Business analyst should be domain expert or a generalist? I was caught up in a similar dilemma some time back and brainstormed with a lot of people having diverse experiences in the industry. Here's my take on the question. It's dependent on various factors :<br /><br />- Industry in which you are working<br /><br />I think being a domain expert might work out as the best solution in primary economic sectors like mining, farming etc. The same would work out in the secondary economic sectors like construction, manufacturing etc and may be in tertiary economic sectors like distribution of manufactured goods. The area of concern is the newly formed industry a.k.a quaternary economic sector which deals with technological research, design and development such as computer programming, and biochemistry. I think a good combination of generalist BA's and domain experts would work out the best in this case. Also, diving more into the IT industry, it's dependent on the type of IT company one belongs to. For e.g. Product development companies would rather have domain experts as the product they are developing would serve a specific industry sector, IT Services companies would have more of generalists as they have varying demands from their clients and they cannot just hire domain experts and wait until they get a suitable assignment. Again the solution I proposed (having right mix of domain experts/generalists looks promising in this case).<br /><br />- Personal interests<br /><br />At the end, the decision to become a domain expert or a generalist is left to an individual.<br /><br />Though I do not have much to say about the pros and cons of each.. just wanted to bring up this thing once again with the broader community and get more opinions!!Nikhil Joshihttp://www.blogger.com/profile/16080430294098801385noreply@blogger.com2tag:blogger.com,1999:blog-5733909393628694215.post-43933732184303202692009-09-23T01:08:00.005+05:302009-09-26T13:08:02.041+05:30Tell stories to your developers, they like it<strong><span class="Apple-style-span" style="font-family:'courier new';"><i><span class="Apple-style-span" style="color:#000099;">sto⋅ry</span></i></span></strong><span class="Apple-style-span" style="font-family:'courier new';"><i><span class="Apple-style-span" style="color:#000099;"><br />–noun<br />a narrative, either true or fictitious, in prose or verse, designed to </span><b><span class="Apple-style-span" style="color:#000099;">interest</span></b><span class="Apple-style-span" style="color:#000099;">, </span><b><span class="Apple-style-span" style="color:#000099;">amuse</span></b><span class="Apple-style-span" style="color:#000099;">, or </span><b><span class="Apple-style-span" style="color:#000099;">instruct </span></b><span class="Apple-style-span" style="color:#000099;">the </span><b><span class="Apple-style-span" style="color:#000099;">hearer </span></b><span class="Apple-style-span" style="color:#000099;">or </span><b><span class="Apple-style-span" style="color:#000099;">reader</span></b><span class="Apple-style-span" style="color:#000099;">; tale.</span></i></span><br /><br /><strong><i>Easy </i>story telling:</strong><br /><br />The above line reveals an important secret: a story is not always read. Given an option, most of us would like to hear the story from story writer rather than reading it. Thus: <div><ul><li>Shouldn’t we write stories in a way it is easy to narrate? (hmmm... 'Narrative'?) </li><li>Is it possible to write a story in a way which is easy to remember after narration?</li></ul><br /><strong>Provide Business Context<br /></strong><br />“Story is designed to <b>interest </b>and <b>amuse </b>the hearer or reader.”</div><div><br />How do I amuse somebody? I guess, by telling something they don’t know Or by confirming/contradicting what they expected to know. </div><div><br /></div><div>The only way amuse a developer to provide a good and interesting business context for the story, at least to confirm what they are expected to know from business perpective. And, if you really able to tell something they don't know, you might really amuse your story <i>listener</i>.<br /><br /><strong>Don’t forget to tell about lead character and his/her interest</strong><br /><br />Are you telling the story of a king or a Queen? It is about a Superhero? </div><div><br /></div><div>Don't worry, if your lead character is a simple user of your application. Everybody likes to find out the lead character of the story and many a times it is a simple user. </div><div><br /></div><div>Hopefully, lead character of your story is very clear in your mind. Would you forget to mention your lead character in your story? Hope not !! It would be a bonus to your <i>listener</i> if you can <a href="http://www.engl.niu.edu/wac/char_sk.html">sketch </a>the character of your story.<br /><br />And what does your lead character wants to achieve in the story? Find Love or take Revenge? Won't you like to share this information with your story listeners?<br /><br /><strong>Write Acceptance Criteria</strong></div><div><b><br /></b></div><div><b><span class="Apple-style-span" style="font-weight: normal;">So, you narrated the story. Your lead character wants to achieve something. Ask your developers to enhance the system in a way that your lead character finds what s/he is looking for. Your lead character might be lucky enough to follow "happy" path or they might take "alternative" routes to find the final destination. </span></b></div><div><br /></div><div><b><span class="Apple-style-span" style="font-weight: normal;">Write acceptance criteria to fulfill wish of your lead criteria and let there be happy ending for your story. </span><br /></b><br />Happy story writing :)</div>Rajiv Sinhahttp://www.blogger.com/profile/05755867860217334944noreply@blogger.com0tag:blogger.com,1999:blog-5733909393628694215.post-3482077808231060222009-08-18T17:02:00.004+05:302009-08-18T17:10:52.556+05:30Business Analyst Check List<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;"><br /></span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;">Going along doing our daily chores on the project there are few things which we should always keep in our to do. Some of them might already be on your checklist</span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><span class="Apple-style-span" style="font-family:verdana;"><br /></span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;">1. </span><b><span class="Apple-style-span" style="font-family:verdana;">Talk to your developers :</span></b><span class="Apple-style-span" style="font-family:verdana;"> The task of analysis is not complete with writing stories. I believe a story or a narrative is just for reference and should not compensate for an in-person communication between you and the developers working on it. In my experience there have been numeral instances where lot of things got uncovered in these conversations which were probably missing in the narrative or the story. The best way to make this happen is to try and sit next to the developer pair who is working on your story. </span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><span class="Apple-style-span" style="font-family:verdana;"><br /></span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;">2. </span><b><span class="Apple-style-span" style="font-family:verdana;">Test your story :</span></b><span class="Apple-style-span" style="font-family:verdana;"> Testing is not just a QAs or a developer's job. As a business analyst it is very important that you test and validate the story for its business completeness. Most of the time a business analyst on the team is acting as a pseudo customer. As we are closest to the business, its us who know most what the story should do and whether it conforms to the business requirement or not. So don't shy away from testing as it very important for your project's success. Most of the projects these days have formal BA sign-off stage for every functional story.</span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><span class="Apple-style-span" style="font-family:verdana;"><br /></span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;">3. </span><b><span class="Apple-style-span" style="font-family:verdana;">Seek early customer feedback :</span></b><span class="Apple-style-span" style="font-family:verdana;"> We have a formal stage in the release or an iteration where we seek customer feedback through showcase. But I would say why wait till then. If there is a feature which is on critical path and requires constant customer input, go an have an informal showcase with the business stakeholder or subject matter expert. Run it on dev box or your machine. </span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><span class="Apple-style-span" style="font-family:verdana;"><br /></span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;">4. </span><b><span class="Apple-style-span" style="font-family:verdana;">Prioritize :</span></b><span class="Apple-style-span" style="font-family:verdana;"> For a release, for an iteration, for a day. And not just stories, defects and tasks too. I know we are not the only actors here but we are one of the important ones. And its important that give our inputs where ever possible. </span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><span class="Apple-style-span" style="font-family:verdana;"><br /></span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;">5. </span><b><span class="Apple-style-span" style="font-family:verdana;">Look at the larger picture : </span></b><span class="Apple-style-span" style="font-family:verdana;">Most of you would agree with me that for a Business Analyst it is very important to know the "WHY" version of every question being asked. Things like why is this project so important to the client's business ?, Why have the priorities changed ?, Why does the client need this feature ?, Why I need to do it this way and not that way ? etc. And the answers for these come when you not only understand the current requirement but where and how it originated from. On my current project, the BAs actively go and surf the internet for any blogs being written about our client, any press releases, any reviews or interviews. We exchange this information among us. This has helped us get answer to most of the whys. </span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><span class="Apple-style-span" style="font-family:verdana;"><br /></span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family:verdana;">If you have a to-do list of your own please share it with us </span></p><div><span class="Apple-style-span" style="font-family:Helvetica, serif;font-size:100%;"><span class="Apple-style-span" style="font-size:12px;"><br /></span></span></div>Rohinihttp://www.blogger.com/profile/17387763752860003293noreply@blogger.com0tag:blogger.com,1999:blog-5733909393628694215.post-37888472612181531952009-07-07T11:22:00.000+05:302009-07-07T11:23:40.025+05:30What skills should business analysts acquire to add value on a project?One way for a business analyst to really add value on a project for a customer is when he/she understands the customer, industry and competition well enough to be able to give valuable solutions and suggestions. Analysts, in most of the projects that I have worked on, do not specialize in a specific domain. They start on a project with very little knowledge of the customer’s business and slowly learn the domain as they go. They are mostly taking requirements from the customer and managing scope. What should the analysts learn in order to really make a difference to the customer (and also remain in business ☺) and how should they go about doing this?Shantalahttp://www.blogger.com/profile/15315301215585999657noreply@blogger.com3tag:blogger.com,1999:blog-5733909393628694215.post-87867215109216494452009-04-11T06:50:00.000+05:302009-04-11T06:52:10.733+05:30Do we need always need business analysts?If the customer is reasonably clear on what they want and the nature of the application is such that unless you have a lot of business domain expertise you cannot really shape the requirements, then isnt it best that the customer interacts directly with the developers and get the app built? An iteration manager to coordinate things might be sufficient... Looks like BAs will be out of business soon ;-)ShareKhanhttp://www.blogger.com/profile/00144902507217458661noreply@blogger.com10tag:blogger.com,1999:blog-5733909393628694215.post-48819919975950710522008-12-06T14:37:00.002+05:302008-12-06T14:59:59.004+05:30Tall storiesShould we always follow the story approach? What if the nature of the beast is that there is a continuously evolving application where one cannot define even a functional test with data? If you define a story, no sooner than its 'complete', it will need to be changed, since new information comes along that makes your acceptance criteria obsolete.<br /><br />Since I am currently experiencing such an approach in a particular area of the project I work in, we are veering round to the view that we need not track velocity or story completion of such work. For purposes of documentation, we will still have stories which detail what work needs to be done at a point of time, but we are not going to bother with tracking the acceptance criteria after that and the points delivered once this work is complete. <br /><br />Comments?ShareKhanhttp://www.blogger.com/profile/00144902507217458661noreply@blogger.com5tag:blogger.com,1999:blog-5733909393628694215.post-32274104812753396572008-10-25T01:44:00.007+05:302008-10-25T12:29:20.131+05:30Estimation - why and why not?I work for a project which follows agile methodology for software development. <br /><br />My team has Programmers, Business Analyst, Testers, Automation engineers, Project Managers, Subject Matter Experts and Customer.<br /><br />When we need to develop a feature, we need to estimate and find out when that feature would be complete. <br /><br />When we need to plan a feature, we ask estimates only from programmers. We don’t really ask estimates from other teams like business analyst team and testing team. <br /><br />Are we doing a bad planning by not asking estimates from analysts and testers? <br /><br />The estimation is one of the attributes requires for planning. We do estimate so that we can plan. So, when we ask estimates from analysis, testing or programming team, it should help us to do planning. If estimation does not help us in planning then we should not estimate.<br /><br />We follow agile methodology, which is more or less similar to Just In Time (JIT) method of manufacturing. We like to keep our inventory level as low as possible. For us, inventory is a piece of requirement, which is termed as “story”. We need to ensure that we have minimal number of stories in pipeline. My pipeline starts when a business analyst starts breaking a “customer need” or "feature" into stories. The pipeline ends when story development is complete and it is ready to go live.<br /><br />I need to plan so that my pipeline is thinner. I should pick up the inventory that i can finish. Thus, I need to know how much programming team can consume in a given time period. Thus we need programming estimates. I also need to know numbers of BAs and Testers needed to support the work that programming team can take. Hence, BA/Testing estimates.<br /><br />Now, let’s take a different point of view. JIT didn't become as popular in USA as it was in Japan. JIT demanded a strict discipline during planning and implementation phase, which many companies in west were not able to adapt. Though, western countries could successfully able to adapt an ‘Avatar’ of JIT called “Theory of Constraints (TOC)”. The basic principal behind TOC was similar to JIT -keep minimum inventory in pipeline. But, it was rather easy to adapt compared to JIT.<br /><br />TOC suggested that the team will move as faster as speed of your bottleneck resource. In a highway, if overtaking is not allowed, the traffic will move with speed of slowest truck and not with speed of a sports vehicle. Thus, you need to ‘estimate’ the throughput only for the bottleneck resource to find how fast the team can go.<br /><br />Applying the same analogy to an agile software development project, we can chart out project plan based on speed of bottleneck resource. To do that, first, we need to find the bottleneck resource. Though, we don’t need estimates from any non-bottleneck resources, we like to closely plan capacity for other resources so that those resources don’t change in a bottleneck. If a non-bottleneck resource changes to a bottleneck, then throughput will be based on speed of new bottleneck. The old bottleneck may not remain that relevant in this scenario.<br /><br />How do we know that a particular resource is becoming bottleneck? The stories will always queued up in-front of bottleneck resource. If your testing team is a bottleneck, you will see lots of stories lined up for testing.<br /><br />If you start with an assumption that your programming team is going to be the bottleneck, then you should do only programming estimates. If you take programming estimates for planning, ensure that small amount of inventory (stories) always piled up before programming team. This is to ensure that bottleneck (or critical resource) is never having dearth of work.<br /><br />The BAs should pile up stories for programming team. The pile in-front of programmers should never be empty. Thus, it is better to have some extra BA capacity so that BA team should always be able to satisfy the need for Dev team. The BA capacity should be increased or reduced based on pile of stories for developers.<br /><br />The Testers should always be free (yes, free) to pick up stories for testing as soon as a programmer completes the stories. There should not be any pile in front of testing team. Again, the testing team capacity should also be closely monitored and adjusted as required.<br /><br />We will agree that the BA and testing team capacity cannot be adjusted on daily basis to achieve the same. The resources take time before they can join the team and be productive. Thus, for a new team, the BAs and testers should be added in a ratio to the programmers and then, should be adjusted to suit the need for the team for first few months.<br /><br />After these adjustments to BA and testing teams, the BA and Testing estimates does not really required for the planning. The programming team sets the pace and BA/testing teams always able to meet that pace as they are extra in capacity. <br /><br />Based on above analogy, I don’t see any reason why any team needs to take estimates from BAs and testers unless they are real bottleneck in the project!! If we think that BAs (or testers) are bottleneck (i.e. critical resources) then we should take estimates only from BAs (or testers) and stop getting estimates from Programming team, as BAs (or testers) will decide when project (or requirement) would be complete !!Rajiv Sinhahttp://www.blogger.com/profile/05755867860217334944noreply@blogger.com2tag:blogger.com,1999:blog-5733909393628694215.post-15193152082756831232008-10-01T00:08:00.006+05:302008-10-06T18:03:38.240+05:30How do I decide optimum release size?<p>So, my project sponsor wants to do a production release every month. He feels that we are not agile enough as we are doing releases only once in 3 months. Our team size is 100+. </p><p>His core reason is : He needs to give the functionality to his customer with shortest lead time possible. Also, he likes to keep giving functionality to his customer one by one rather than in one go. </p><p><br />If we make release duration too short, it will not allow us to complete some features scheduled in the release. This is an extra overhead for the release when a feature is not production ready, as dev team needs to switch off that functionality and QAs needs to ensure that all workflows works fine after switching off the half baked feature. </p><p>So, what are the factors that i should consider before deciding on a release size?<br /></p>Rajiv Sinhahttp://www.blogger.com/profile/05755867860217334944noreply@blogger.com3tag:blogger.com,1999:blog-5733909393628694215.post-61820089702722439342008-09-23T12:52:00.004+05:302008-09-23T16:39:03.455+05:30User Stories: Value and Size<div style="text-align: justify;">ShareKhan brought up the issue of story value and size in his recent post here. My comment was getting too long so here's a post.<br /><br />There are three different issues that ShareKhan is talking about:<br /></div><ol style="text-align: justify;"><li>Business value of a functional story</li><li>The reason for splitting requirements into stories AND<br /></li><li>The practice of "storying up" technical / environmental tasks</li></ol><div style="text-align: justify;"><span style="font-weight: bold;">Business value of a functional story</span><br />Maximizing work not done is the art of our trade. The business value of a story is looked into precisely for this reason. If you don't have a good reason (<span style="font-weight: bold;">business value</span>) behind a given piece of functionality (<span style="font-weight: bold;">story</span>), you are wasting time by working on it.<br /><br />This means that technical necessities, like refactoring of code, also have to pass the business value test to be played. They are not stories by themselves at all. Refactoring happens as part of a functional story which requires the code to change in a certain way.<br /><br /><span style="font-weight: bold;">Splitting requirements into small stories</span><br />The basic reason why we split requirements into stories is to deliver working software to the client as soon as possible and get her feedback on it. Development convenience, Better tracking of the iteration progress / velocity, etc are just side effects of having small stories.<br /><br />Another thing that we aim at doing is delivering value (read "usable software") with every build. This means that if the plug is pulled, the client still walks away with something she can use. Of course, if you pull the plug after the first day itself (like in ShareKhan's example) you won't get much but I guess that's true for anything in life.<br /><br />What small stories do is they let you build a coherent piece of software that has some value. Let's say we have the following stories.<br /><ol><li>As a sales person, I should be able to enter the product code by typing it in</li><li>As a sales person, I should be able to enter the product code by scanning the barcode</li><li>As a sales person, I should be able to enter the product code by scanning the RFID tag</li><li>As a sales person, I should be able to make a sale for the product entered</li><li>As a customer, I'd like to get an itemized bill for the products that I bought</li></ol><br />I'd have 1, 4 and 5 built first and keep 2 and 3 as niceties. If the client pulls the plug after 3 stories, she still ends up with a system that let's her sell products. Now if you don't do it this way, your client ends up with a piece of software that can take in a product code in multiple ways but can't make a sale. Making a sale is the crux of the system (taking the POS example from ShareKhan's post).<br /><br /><span style="font-weight: bold;">Technical / Environment / Infrastructure tasks and the practice of tracking them as stories</span><br />I think my main problem is with calling these "stories", unless you can actually clearly define the value that they bring. Most of the times the value of such tasks is as vague / intangible as your NFRs. You know these tasks are valuable but it's a waste of time trying to find out and put down in words exactly what value they bring in. I don't even think that it affects prioritization of these tasks in any way.<br /><br />That leaves one problem, tracking and I think we should track them as convenient to the project. Track them as cards, count them in velocity, deduct time spent on such tasks from development capacity. Anything that suits you and the client.<br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com3tag:blogger.com,1999:blog-5733909393628694215.post-67259247243197044932008-09-19T11:48:00.003+05:302008-09-23T12:47:31.803+05:30When do you decide that a story has business value?We were discussing an issue with a client today. It was about getting some hardware installed that involved a series of tasks like getting racks, loading them, having the machines setup with some config and so on. The person in charge of this area was asking for stories to be created for each of these tasks "so that the work could be tracked". <br /><br />The manager we were talking to was questioning the value of this with the logic that these are just simple tasks that need to be done by one small team to get the machines installed. How will having stories to track this help?<br /><br />The idea of having a story is to track how delivering upon a small discrete requirement can generate business value for the business. Whats the point of generating more overhead with creating, delivering to and tracking a story for such low level tasks?<br /><br />Then I thought, how do you quantify this business value per story? If the complete goal is to build a retail POS system, then what business value can I have by just getting a story to work where it lets the user scan a barcode and have the value register? If the rest of the system (and maybe 200+ stories) don't get done or don't work, then the miniscule "business value" of this scanning story is meaningless.<br /><br />So then at what level does story breakdown make sense? To me, it now seems more of a development nicety to break it down so it fits in an iteration, give closure, blah blah.ShareKhanhttp://www.blogger.com/profile/00144902507217458661noreply@blogger.com2tag:blogger.com,1999:blog-5733909393628694215.post-23824199049129405322008-09-11T15:58:00.001+05:302008-09-12T20:19:54.640+05:30Align Software to Business Goal !!<p style="TEXT-ALIGN: justify"><em>This article stress on understanding the <a href="http://www.outside-in-development.com/objectives/measurable_business_objectives.html">Business Goal</a> on first opportunity available.</em></p><p style="TEXT-ALIGN: justify"><strong>Board Room of Chief Technology Officer (CTO) , Star Hotel, London</strong></p><p style="TEXT-ALIGN: justify">There were 3 people in the room discussing the need to improve the existing portal of the Hotel.</p><p style="TEXT-ALIGN: justify"><strong><em>CTO:</em></strong> Current portal is really slow. I guess that user like to visit our site but they leave the site before all information loaded to the website. </p><p style="TEXT-ALIGN: justify"><em><strong>Product Owner:</strong></em> I am not able to showcase new offers efficiently through current website. I need to take approval from two different groups before I can talk to administrator of the portal to load new offers. 90% of time, the administrator ask me to make changes to offer details due to technical limitation. </p><p style="TEXT-ALIGN: justify"><em><strong>Technical Architect:</strong></em> It seems that current portal needs to be replaced by a new one. My team can re-write it using a new technology and develop the software based on new requirements to support your needs. </p><p style="TEXT-ALIGN: justify"><em><strong>CTO:</strong></em> I would rather like to re-use the current portal. If you need budget to enhance the existing portal, I am ready to get the budget for that. But I don’t want to invest for building a new portal unless really needed.</p><p style="TEXT-ALIGN: justify"><em><strong>Technical Architect:</strong></em> If the problem is only to improve the performance and manage the promotions of new offers, we can solve your problems by refactoring some of the code. But, still we need to re-write some part of functionality to accommodate new requirements.</p><p style="TEXT-ALIGN: justify"><em><strong>CTO:</strong></em> I am OK with that. So, we are clear on what we need. I want two of you to work together and come back with estimated cost for this enhancement.</p><p style="TEXT-ALIGN: justify"><em><strong>CTO:</strong></em> One more Point ! We recently hired a business analyst to help our team on gathering requirements for new software projects. Do you want to involve him on this now? </p><p style="TEXT-ALIGN: justify"><em><strong>Product Owner:</strong></em> Na… as of now, we are not clear on what we need. I will work with technical team to get more clarity on complexity of implementing some of my requirements. We can involve the business analyst later. </p><p style="TEXT-ALIGN: justify">The Product Owner and Technical Architect worked on understanding the requirements for a month and gave proposal to CTO. </p><p style="TEXT-ALIGN: justify">CTO gets the approval from Chief Executive Officer (CEO) and asks team to start the work.</p><p style="TEXT-ALIGN: justify">Now, the team decided to bring the business analyst to enhance the functional requirements. </p><p style="TEXT-ALIGN: justify"><strong><em>Question </em><br /></strong>At this point of time, is it possible for business analyst to align the software development work with business goals? </p><p style="TEXT-ALIGN: justify"><em>My Opinion</em><br />Yes, the business analyst should still be able to work with the team to come up with a new/modified plan and requirement list which is aligned to the business goals, though if the team would have involved her in the initial stages of discussion, it would have been faster and easier.</p><p style="TEXT-ALIGN: justify"></p><p style="TEXT-ALIGN: justify"><strong><em>Question<br /></em></strong>What if the business analyst doesn’t question to find out the goals for the business and need for developing the software because she got involved late in the process? </p><p style="TEXT-ALIGN: justify"><em>My Opinion<br /></em>It is a big risk. The software might be technically sound but the investment on software may not improve revenue situation for the company. It may also result into the re-write of the portal very soon in near future.</p><p style="TEXT-ALIGN: justify"><strong>Conclusion<br /></strong>Understanding the business need for the software is important. No matter when a business analyst starts working on the project, she should always start on project by understanding the business goals that should be fulfilled after development of software.<br /></p>Rajiv Sinhahttp://www.blogger.com/profile/05755867860217334944noreply@blogger.com1tag:blogger.com,1999:blog-5733909393628694215.post-79722916968556905142008-09-11T15:15:00.001+05:302008-09-12T00:59:41.110+05:30Business analysis and quantum physics<div style="text-align: justify;"><a href="http://en.wikipedia.org/wiki/In_Search_of_Schr%C3%B6dinger%27s_Cat">In search of Shrödinger's cat</a> is a wonderful introduction to quantum mechanics. The basic (and intriguing) problem of the elusive electron <a href="http://en.wikipedia.org/wiki/Wave-particle_duality">acting as a wave and a particle</a> at the same time.<br /><br />Analysis is very much like observing the electron in the <a href="http://www.colorado.edu/physics/2000/schroedinger/two-slit2.html">classic two slit experiment</a>. The business domain is like a wave traveling through the two slits. But the moment we analyze, we make it boil down to one reality by asking it How, What, When and Who.<br /><br />Waves give you a probability distribution, while particles give you one of the possibilities as a reality. Looking at a business problem, in the wave form is better since it let's you choose a reality that solves the problem well.<br /><br />For Example: Let's say the business problem is <span style="font-style: italic;">"I want to let my customers know of the new offers I have so that they can take advantage of the offers and I can make money"</span><br /><br />This is the problem in it's wave form. The reality can be one or more of email, website updates, RSS feed of offers, people going door-to-door, mobile advertisement vans and a million other options including telepathy, albeit with low probability perhaps.<br /><br />The problem is that clients come and say <span style="font-style: italic;">"I want to let my customers know of the new offers I have </span><span style="font-weight: bold; font-style: italic;">by email</span><span style="font-style: italic;"> so that they can take advantage of the offers and I can make money"</span> and it takes a while to get into a mode where you challenge every reality and go back to the wave form, by asking "Why"? Why is the only question that let's you go back to the wave form.<br /><br />The more we procrastinate our observation, the better will the chosen reality suit our problem. Agile takes this approach with the concept of the last responsible moment for a decision. It let's future remain future and hence full of possibilities.<br /><span style="font-style: italic;"><span style="font-style: italic;"></span></span></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com0tag:blogger.com,1999:blog-5733909393628694215.post-13071430672334491212008-09-11T10:01:00.001+05:302008-09-11T17:50:10.978+05:30When do you need a business analyst<div style="text-align: justify;">So I'm working for a client where they practice Agile, but do not have the role of a business analyst. They prefer to have their business users work closely with the development teams, calling this role that of a product manager. The people in these roles are subject matter experts who understand the business very well and have been trained well in Agile concepts.<br /><br />However, when it comes to working with the development team, its difficult for them to always provide information in the form that developers can consume. At several times, we have seen that the role of an analyst is needed to bring consensus on requirements within the different business groups and to structure and sequence functionality such that the best interests of the project are always upheld.<br /><br />The work involved is fairly spread across various systems and not contained to a small area. I think that if the latter was the case, then perhaps we could have got by without any analyst role.</div>ShareKhanhttp://www.blogger.com/profile/00144902507217458661noreply@blogger.com1