<?xml version="1.0"?><rss version="2.0" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>Agile Analysis &amp; Techniques</title><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/scope/threads/Default.aspx</link><description>Discuss the role of the Business Analyst in an Agile environment as well as related topics.</description><pubDate>2026-04-28T22:11:38Z</pubDate><lastBuildDate>2025-04-03T05:37:06Z</lastBuildDate><ttl>30</ttl><item><title>GUIDELINES - How to use this forum!</title><pubDate>2009-02-22T23:39:13Z</pubDate><author>ModernAnalyst.com</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/3102/scope/posts/Default.aspx</link><description>
&lt;span style='font-size: medium'&gt;&amp;#160;Use this forum to post questions and start discussions related to:



    &lt;span style='font-size: medium'&gt;The role of the business analyst in an Agile environment,

    &lt;span style='font-size: medium'&gt;Agile businness analysis,

    &lt;span style='font-size: medium'&gt;Agile requirements,

    &lt;span style='font-size: medium'&gt;Agile tools and techniques for the BA,

    &lt;span style='font-size: medium'&gt;etc.


</description><slash:comments>0</slash:comments></item><item><title>User stories vs requirements </title><pubDate>2024-07-26T15:47:33Z</pubDate><author>Jw3000</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/13373/scope/posts/Default.aspx</link><description>
I&amp;#39;m trying to understand the different between a user story and a requirement.Is there a hierachy like the requirements come first and then user stories created in the backlog. Maybe I&amp;#39;m confusing myself but always thought the user stories are just a way of representing a requirement and then acceptance criteria is the functional aspect? But then unsure how this relates to a product requirements document?I often hear that agile doesn&amp;#39;t mean you don&amp;#39;t have a requirements document,so how does that relate and interact with the user stories? I Would really appreciate some input to how everyone structures and approaches the documentation of requirements in agile.



 

</description><slash:comments>10</slash:comments></item><item><title>In software development, what is Agile?</title><pubDate>2023-02-14T08:06:11Z</pubDate><author>Ethan Klein</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12683/scope/posts/Default.aspx</link><description>Agile is an iterative method for managing projects and creating software that enables teams to serve customers more quickly and without as many hassles. An agile team produces work in small, consumable increments as opposed to placing all of their eggs in one big 'big bang' launch.
</description><slash:comments>22</slash:comments></item><item><title>Is Business Analyst Position needed in Agile SDLC at all?</title><pubDate>2016-06-08T17:43:38Z</pubDate><author>kremnos</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/10224/scope/posts/Default.aspx</link><description>
 




Hi all,





I have a question for my experienced fellows business analysts. 





I'm studying business analysis and got confused recently.





Forgive me my ignorance, but I don't quite understand how a business analyst position fit into an agile driven project. 





I mean, what would be BA's responsibilities in real world situation in real world company in the real world agile project? 


How would they be different from those in classic Waterfall SDLC? 





Is a BA position needed in agile SDLC at all?





I heard the opinion that 'Scrum killed BAs'. Is this statement correct?





If somebody had the pleasure to work in both Waterfall and Agile methodologies as a BA, her/his advice would be priceless.





Thank you in advance!





Most sincerely,





Alex


&lt;div&gt;


&lt;/div&gt;</description><slash:comments>14</slash:comments></item><item><title>Agile needed or just another re-invention of the wheel?</title><pubDate>2020-01-31T03:18:47Z</pubDate><author>UserFocussedAnalysis</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/11543/scope/posts/Default.aspx</link><description>Ive been in IT going on a few decades now, I do BA work and usually people hire me to be the PM, BA, SA (assistant), DBA, Tester etc, copy and insert SDLC roles.





And Im ok with this.





But I look at Agile, which Im certified in, and I wonder is this another ITIL, that for some reason people feel necessarry when really it isn't. Aside from naming roles and processes around Rugby Union, which I find incredibly unprofessional, I don't see as a Project Manager or a BA or a UX designer or any role, how it really improved anything.





If you run Prince 2 as PM methodology and you use RAD as your iteration methodology, you should be effectively doing the same objective but with faster and more defined iterations, requirements, testing, acceptance, whatever part of the SDLC you want to critique.





I just feel Agile whilst if you ignore is silly naming conventions, can (not always) improve iteration speed its an ok method.





But why re invent the wheel when Water Fall with RAD iterations does the same think but with clearer objectives and roles. 





Ive run projects with both and I see far better results with Prince 2 methods, providing you also use Rapid Application Development.





I think Agile folk got this idea in their head that waterfall means slow year long iterations, and perhaps they worked in government type sectors where that was the case, while rest of us were pumping out weekly or bi weekly iterations with full tested use cases that are then signed off by the Sponsor and or Stakeholder/s.





Interested to hear other experiences with rapid waterfall development vs agile.......





Unfortunately its there now and its something one has to know how to run given its been sold as more 'Agile' when IMO thats a false narrative based on situations where SDLC is run unnecessarily slow (perhaps on purpose in some instances)





Please, this is not a beat up on Agile, more a curiosity as to where slow Waterfall SDLC created the proposed need for agile. The concept is a good one, its just I feel its already there and has been the whole time, depending on who is running the SDLC and with what methods. :-)</description><slash:comments>16</slash:comments></item><item><title>Okta apps validation</title><pubDate>2024-08-05T12:11:03Z</pubDate><author>hemanth4</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/13397/scope/posts/Default.aspx</link><description>
I have 3 okta apps setup.




 Okta app for backend

 Okta spa app

 Okta web app





The Okta spa app is able to use the access token it got and pass to Okta app for backend and the token is validated. However, the Okta web app access token when passed to Okta app for backend, could not be validated, thus token is not valid.



Anyone know the proper setup for the Okta web app so where its access token can be validated against the Okta app for backend?

</description><slash:comments>0</slash:comments></item><item><title>In software development, what is Agile?</title><pubDate>2024-08-02T09:32:47Z</pubDate><author>Rohan77</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/13389/scope/posts/Default.aspx</link><description>
Agile is a flexible and iterative approach to software development that emphasizes collaboration, customer feedback, and rapid delivery. Instead of working through a rigid plan&lt;span style='font-size:12px;'&gt;'https://scholarshipup.org/'&gt;, Agile allows teams to adapt to changes and deliver functional increments of the product regularly. This methodology fosters continuous improvement and responsiveness to user needs, promoting a more efficient and dynamic development process.

</description><slash:comments>0</slash:comments></item><item><title>RPA (Robotic Process Automation)</title><pubDate>2021-09-16T15:30:06Z</pubDate><author>Tracy_CC1</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12209/scope/posts/Default.aspx</link><description>
Does anyone have any slide decks for me on RPA? 

</description><slash:comments>6</slash:comments></item><item><title>User Roles or Privileges screen for intranet application </title><pubDate>2023-11-13T00:24:06Z</pubDate><author>Samigget</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/13011/scope/posts/Default.aspx</link><description>
I am trying to details user stories on a &amp;#39;User Role and Privileges&amp;#39; screen for an Intranet web application GUI part.



And its a mix and match of Few screens and their within functionality access.


The usual way is having a matrix like structure where we can list down screen names/Interfaces and then in the 2nd step user can choose between the function allowed for that role within the selected screen. 



Is there any GUI idea someone have come across, other than this traditional two step approach (an out of the box, of fancy GUI for Roles screen)? 


 



Thanks

</description><slash:comments>0</slash:comments></item><item><title>Why is Agile so Popular?</title><pubDate>2023-07-12T13:13:04Z</pubDate><author>XDuce Corporation</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12876/scope/posts/Default.aspx</link><description>&lt;section data-element_type='section' data-id='85fb143'&gt;

Before Agile, the Waterfall methodology was the gold standard for Software Development. Developing any software product required a ton of documentation before coding even began. Business analysts prepared the requirements documentation, technical department then prepared their technical requirement documentation from it. Then coding and testing come to the floor.



Agile methodology overcomes the risk of spending a lot of time if there are any changes required. It allows teams to work directly with clients, instead of working with other teams. This provides a clear outcome with a focused goal and in an incremental way. 



From a variety of viewpoints, organizations considered Agile to be more beneficial than the waterfall process. Agile is prevalent in the manufacturing, FMCG, and car industries, in addition to the IT business.

&lt;/section&gt;

&lt;section data-element_type='section' data-id='40d36cd'&gt;XDuce (https://xduce.com/custom-software-development) adapted Agile methodology many years ago. We worked for the betterment of our clients. A V-shaped model is a good option for companies, combining quick turnaround times in Agile with detailed planning and documentation of Waterfall.&lt;/section&gt;
</description><slash:comments>6</slash:comments></item><item><title>Business Analyst In Agile - Here is why you need them, sometimes</title><pubDate>2023-07-16T18:26:30Z</pubDate><author>Meta BA</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12878/scope/posts/Default.aspx</link><description>
The question of whether you need BAs in Agile comes up quite often, but it&amp;#39;s not exactly the right question. The circumstance in which a BA adds value is totally independent of the methodology. It comes down to the complexity of the organization. Business analysts add value when the organization is so large and complex that there needs to be people dedicated to investigating, analyzing, navigating, and communicating that complexity. If the organization is not large or complex, then you likely don&amp;#39;t need a dedicated business analyst regardless of the software development lifecycle. Here is a video walking through the relationship of a 'https://youtu.be/p5EeBfXcEKQ' target='_blank'&gt;Business Analyst on an Agile Team

</description><slash:comments>6</slash:comments></item><item><title>Next Steps As An AGILE BA</title><pubDate>2023-08-31T10:29:23Z</pubDate><author>markyjane</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12935/scope/posts/Default.aspx</link><description>
I have a lot of questions with regards to becoming an AGILE BA.





I will be working on an EPIC very soon. However, in the meantime, the product owner has assigned me a number of user stories to work on. These are within the &amp;#39;TO DO&amp;#39; column on KANBAN.



 



What do I do when they are in the TO DO column?





After I have completed what would have been needed to do on the story, what is the next step after that?






When it comes to changing the status of a story who does that? myself or the product owner?



 



Do I need to reassign a story to a tech/dev person once I have completed working on the story or?



 



Are there any liaising I need to do with the users/stakeholders within the &amp;#39;TO DO&amp;#39; part? Or would this have already been covered off by the product owner?



 



Just looking for a clear and concise logical flow of what and how the process would be/looks like working on a story and how it flows through/who changes what on the status/ etc , etc



 



Many thanks!!!

</description><slash:comments>5</slash:comments></item><item><title>Acceptance Criteria</title><pubDate>2023-09-22T17:15:20Z</pubDate><author>MadiMo</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12951/scope/posts/Default.aspx</link><description>
Hello,



I just wonder when do you actually write the Acceptance Criteria? And HOW Do you elicit it?



I know it is before the development phase, but when exactly? Is it at the time you elicit the User Stories?



Many thanks for your experience



Madi

</description><slash:comments>4</slash:comments></item><item><title>The Lean Start Up for Business Analysts</title><pubDate>2023-06-22T23:57:57Z</pubDate><author>The BBAI</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12856/scope/posts/Default.aspx</link><description>
Benjamen Walsh from The Better Business Analysis Institute talks about The Lean Start Up For Business Analysts. Written by Eric Ries.



Listen here on Spotify: https://open.spotify.com/episode/73TFbOJZwGrQhdG0uzp3M5?si=NwzHt7kDRC6fR4GbhtOCRA



The lean startup methodology emphasizes customer feedback over intuition and flexibility over planning. This methodology enables recovery from failures more often than traditional ways of product development.



Here are the key principles of the lean startup:




 Build-Measure-Learn: This is the core feedback loop of the lean startup methodology. It involves building a minimum viable product (MVP), measuring how customers use it, and learning from the data to improve the product.

 Validated learning: This is the process of using data to measure whether or not your hypotheses about your customers are correct. This allows you to make better decisions about how to develop your product and business model.

 Pivot or persevere: Based on the learnings from the build-measure-learn loop, you may need to pivot your business model or persevere with your current approach.

 Customer development: This is the process of understanding your customers and their needs. It involves talking to customers, conducting surveys, and running experiments.

 Continuous improvement: The lean startup methodology is an iterative process. You should continuously improve your product and business model based on the feedback you receive from customers.





The lean startup methodology has been used by many successful companies, including Airbnb, Dropbox, and Stripe. It is a powerful tool that can help you build a successful business.



Here are some additional benefits of using the lean startup methodology:




 Reduced risk: The lean startup methodology helps you reduce the risk of failure by allowing you to test your hypotheses and learn from your mistakes early on.

 Increased speed to market: The lean startup methodology can help you get your product to market faster by allowing you to iterate on your product based on customer feedback.

 Improved decision-making: The lean startup methodology helps you make better decisions about your business by providing you with data-driven insights into your customers and their needs.





If you are a startup founder or entrepreneur, the lean startup methodology is a valuable tool that can help you build a successful business.



Sure, here are some of the different types of MVPs covered in the lean startup:




 Concierge MVP: This is a type of MVP where you provide a service to customers manually, instead of automating it. This can be a good way to test the demand for your product before you invest in building a full-featured product.

 Wizard of Oz MVP: This is a type of MVP where you use automation to simulate a fully-functional product. This can be a good way to test the user experience of your product before you invest in building the full feature set.

 Landing page MVP: This is a type of MVP where you create a landing page for your product and collect email addresses from potential customers. This can be a good way to gauge interest in your product before you invest in building it.

 Minimum lovable product (MLP): This is a type of MVP that focuses on creating a product that is both functional and appealing to users. The goal of an MLP is to create a product that users love to use, even if it doesn&amp;#39;t have all of the features that they would eventually want.

 Minimum viable feature (MVF): This is a type of MVP that focuses on building a single, core feature of your product. The goal of an MVF is to get your product to market as quickly as possible and start collecting feedback from users.





The type of MVP that you choose will depend on your specific product and business goals. However, all MVPs share the same goal of helping you learn more about your customers and their needs so that you can build a product that they love.



#BusinessAnalysisTraining

</description><slash:comments>2</slash:comments></item><item><title>Agile Software Development - a people orientated methodology...</title><pubDate>2009-10-01T10:03:27Z</pubDate><author>Mark Ridgwell</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/3816/scope/posts/Default.aspx</link><description>
Agile Development minimizes risks by developing software in short amounts of time - in iterations that typically lasts from two to four weeks. Each iteration passes through a full software development cycle and a release - without bugs - available at the end of each iteration. Agile Software Development is a conceptual framework for software development that promotes development iterations, open collaboration, and adaptability throughout the life-cycle of the project.



There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration. Each iteration passes through a full software development cycle, including planning, requirements analysis, design, writing unit tests, then coding until the unit tests pass and a working product is finally demonstrated to stakeholders. Documentation is no different than software design and coding. It, too, is produced as required by stakeholders. An iteration may not add enough functionality to warrant releasing the product to market, but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, stakeholders re-evaluate project priorities with a view to optimizing their return on investment...


 

</description><slash:comments>7</slash:comments></item><item><title>Is Business Analyst Position needed in Agile SDLC at all?</title><pubDate>2016-06-04T00:52:06Z</pubDate><author>kremnos</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/10221/scope/posts/Default.aspx</link><description>
 




Hi all,





I have a question for my experienced fellows business analysts. 





I'm studying business analysis and got confused recently.





Forgive me my ignorance, but I don't quite understand how a business analyst position fit into an agile driven project. 





I mean, what would be BA's responsibilities in real world situation in real world company in the real world agile project? 


How would they be different from those in classic Waterfall SDLC? 





Is a BA position needed in agile SDLC at all?





I heard the opinion that 'Scrum killed BAs'. Is this statement correct?





If somebody had the pleasure to work in both Waterfall and Agile methodologies as a BA, her/his advice would be priceless.





Thank you in advance!





Most sincerely,





Alex


&lt;div&gt;


&lt;/div&gt;</description><slash:comments>13</slash:comments></item><item><title>SRD</title><pubDate>2022-06-28T20:28:43Z</pubDate><author>NiravP</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12484/scope/posts/Default.aspx</link><description>
Hello Everyone,



I&amp;#39;m new to the field of BA and would like to make a career. I&amp;#39;m currently under coaching and have various assingments to do. I was lookig  for some help here on how to write a SRD. Suggestions welcome.

</description><slash:comments>1</slash:comments></item><item><title>Agile iteration size pros and cons</title><pubDate>2018-01-26T12:28:06Z</pubDate><author>rdonohoe</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/10853/scope/posts/Default.aspx</link><description>
My large multi-year project is moving to Agile and the policy is for agile iterations between 2 and 4 weeks in length.  We are debating which is better to start with - 2 week or 4 week iterations.  Anyone care to reply with pros and cons for each?  Our direct team has little agile experience and we are about evenly split, so I have the task of researching pros and cons of each choice.
</description><slash:comments>14</slash:comments></item><item><title>3 Amigo's Sessions</title><pubDate>2022-05-30T12:08:47Z</pubDate><author>Stewart F</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12462/scope/posts/Default.aspx</link><description>
I&amp;#39;ve just hired a new Senior BA for my team. One of the reasons I chose them was that he had lots of different ideas for running Agile based ceremonies and I thought it mught be good to incorporate some of them into the team that i run. 



One of those ceremonies is the 3 Amigos session. We currently hold them - one for every User Story and it is more a validation exercise for what the BA has written, than being a team discussion about upcoming work. I&amp;#39;m not convienced that is the best way we should be conducting them. 



For those of you who may not have heard or been involved in one of these, a 3 AMigos session involve 3 key people in the Squad or Team involved in your project. Usually it is the BA, a developer and a tester. A fourth amigo - usually a deisgner is often invited as well, depending on the User Story/Project. 



The session involves havng the User Story in front of everyone and talking through and refining its goals, Acceptence Criteria and how it potentially will be acheived. The small group talk through each AC until everyone is agreed and the Story can be moved forward to the Design team or Developers - again, depending on what the User Story is for. 



An Amigos session should really be no more than 10 minutes per User Story - but in reality it has no time limit and, if there is a lot ot discuss, the Story may need more refining/re-writing. 



&lt;u&gt;The Question&lt;/u&gt;



My question is this though - how do you think they are best run - I&amp;#39;m curious to see what other ways people on this forum have to run a 3 Amigos and how they run it. Some exmples of potential questions:



a. Do you fully write the User Story first as the BA, and then discuss in the session OR do you start with the bare bones and add whatever is discussed?



b. Do you add new requirements in the session, or take them away for further analysis? 



c. How many times will you re-do an Amigos session for one User Story - do you have a limit?



This is more for an open discussion and to see what other peoples ideas are - their problems, stories or past issues with 3 Amigos etc.

</description><slash:comments>1</slash:comments></item><item><title>3 Amigo's Sessions</title><pubDate>2022-05-30T12:08:33Z</pubDate><author>Stewart F</author><link>https://modernanalyst.com/Careers/CareerForums/tabid/77/forumid/30/threadid/12461/scope/posts/Default.aspx</link><description>
I&amp;#39;ve just hired a new Senior BA for my team. One of the reasons I chose them was that he had lots of different ideas for running Agile based ceremonies and I thought it mught be good to incorporate some of them into the team that i run. 



One of those ceremonies is the 3 Amigos session. We currently hold them - one for every User Story and it is more a validation exercise for what the BA has written, than being a team discussion about upcoming work. I&amp;#39;m not convienced that is the best way we should be conducting them. 



For those of you who may not have heard or been involved in one of these, a 3 AMigos session involve 3 key people in the Squad or Team involved in your project. Usually it is the BA, a developer and a tester. A fourth amigo - usually a deisgner is often invited as well, depending on the User Story/Project. 



The session involves havng the User Story in front of everyone and talking through and refining its goals, Acceptence Criteria and how it potentially will be acheived. The small group talk through each AC until everyone is agreed and the Story can be moved forward to the Design team or Developers - again, depending on what the User Story is for. 



An Amigos session should really be no more than 10 minutes per User Story - but in reality it has no time limit and, if there is a lot ot discuss, the Story may need more refining/re-writing. 



&lt;u&gt;The Question&lt;/u&gt;



My question is this though - how do you think they are best run - I&amp;#39;m curious to see what other ways people on this forum have to run a 3 Amigos and how they run it. Some exmples of potential questions:



a. Do you fully write the User Story first as the BA, and then discuss in the session OR do you start with the bare bones and add whatever is discussed?



b. Do you add new requirements in the session, or take them away for further analysis? 



c. How many times will you re-do an Amigos session for one User Story - do you have a limit?



This is more for an open discussion and to see what other peoples ideas are - their problems, stories or past issues with 3 Amigos etc.

</description><slash:comments>0</slash:comments></item></channel></rss>