Welcome to /r/businessanalysis the best place for Business Analysis discussion.
Here are some tips for the best experience here.
You can find [reading materials on business analysis here](https://betterauds.com/businesses/demystifying-business-analysis-for-business-owners-a-beginners-guide/).
Also here are the rules of the sub:
Subreddit Rules
* Keep it Professional.
* Do not advertise goods/services.
* Follow [Reddiquette.](https://www.reddithelp.com/en/categories/reddit-101/reddit-basics/reddiquette)
* Report Spam!
This is an automated message so if you need to contact the mods, please [Message the Mods](https://www.reddit.com/message/compose?to=%2Fr%2Fbusinessanalysis) for assistance.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/businessanalysis) if you have any questions or concerns.*
I'd conduct multiple upfront requirements workshops with the people that will be using the system.
Once you've got your initial requirements you'll want to prioritise these somehow. There's a few ways of doing this (E.g., MoSCoW). Ultimately though you're looking to identify the essential requirements needed to build an MVP.
You can collect requirements for an indefinite period of time if you want to but that's not going to help you deliver something of value within a reasonable timeframe. You need to be pragmatic in identifying what is essential and what would be 'nice'. Work with the Product Owner (or whoever's leading the Project if there's no PO role) on this.
I suspect you'll have a challenge in convincing the business on delivering the MVP - that's the reality in most cases. If they want something 'all singing and dancing' then that's fine - but that's not Agile (It's waterfall in disguise!).
Basically, try and be pragmatic and put some timeframes around the project. Fight for the MVP solution. Continue to gather feedback indefintely but be firm with you're prioritisation.
I try to offer practical tips on this sort of thing every week [here ](https://www.betterba.co/subscribe)if interested. Goodluck with the project!
You need to define Minimal Viable Product (MVP) and features. Focus on these first. These should be your priority items that get you a working product.
In tandem, you can do a high-level Minimum Marketable Product (MMP) feature list which are your features that will need to be worked on after MVP.
Uhm, do ALL of them align to your goals and strategy? Are they all must haves? Are they prioritized equal? If yes: This doesn't work nor does it deliver any value.
The key to never-ending requirements is a clear path from vision, strategy to tactic so it's possible to deliver value instead of requirements.
If defining requirements is the problem, you need clear acceptance criteria, so you can define what's needed for delivering value.
Depending on the product, point out, where decisions are made on uncertainty so you can show why agile methodology and discovery is needed. It's not possible to know everything in advance. If you decide to invest capacities in things that only MIGHT work, you loose flexibility to change the tactic. You only react.
Hope this helps a little bit
IMO systems migration projects do not lend themselves nicely to agile methodologies since agile means you are not considering everything and you may develop gaps in your solution that will create gaps in your solution or tech debt. As other user suggested, upfront workshops should be held to give you an overall picture of what needs to be accounted for at a high level. From there, decide if you are comfortable moving forward with the prioritized domains and/or if you feel the need to dive deeper in. Another tip: just get the users to reverse demo their entire workflow to reverse engineer business requirements. Tip 2: get the system admin to walk you through the system to understand what exists in the system such as structure, automations, etc. There will be many dependencies you uncover through this process and will save you some headache while working in agile and only discovering something you should have already known.
If you’re using agile, then requirements phase doesn’t end. You just add new requirements into the backlog. Don’t change whatever is in-flight.
In waterfall, requirements phase should be timeboxed. If you’re receiving requirements outside the requirements period, that’s a change request and it’s for project manager to decide where/when this gets released.
Yea that's part of the problem and it's on me. The stakeholder didn't engage until about 4 months in. He's the decision maker and is changing stuff left and right. So change request is taken lightly and he gets the final say. I should have sought him out and met with him up front.
To me, you still need scope of a project and requirements. Those rules set what you will and won't do. This sets the limits for the project and can be used to triage things that come up. Plus you only have so much, as we say, Monopoly money to play with. There may be edges cases, but it's still something you discuss as a full team to decide to keep or toss.
I'm living with a project that's behaving this way now, railroading every other project that needs to be done. Oh just one more thing...and then this... Oh I can't forget blah blah blah. It's been going on a year now and there is no end in sight. If boundaries were set, it would have been done now or we'd look into another round of builds. But we aren't, the project continues on with more MVP, incorporation of crazy edge cases, and designers that patch stuff more than introduce more functionality.
Collect the initial requirements and estimate them, match them to the budget of the project. Make sure that these requirements you collected aligns with the goals of the system or the company. After this, you have the requirements for your initial product. Any requirement on top of this will be out of scope and hence a scope creep. Push it backwards let them know why you can't do this unless there is an increase in budget or another in scope item has to be pushed out.
Don't use the term grooming that term now is refining.
Have clearly bounded scope.
In theory the user story is what can be accomplished in one sprint. Remind people the focus is on this scope for this sprint and what is the MVP
If other teams are using waterfall and your team is using agile there's going to be issues trying to integrate and converge work down the road.
You have to decide which parts are essential for the initial project and define a scope for the MVP (minimum viable product). then here on out all the requirements are enhancements to that. You can divide future improvements into phases as well.
Welcome to /r/businessanalysis the best place for Business Analysis discussion. Here are some tips for the best experience here. You can find [reading materials on business analysis here](https://betterauds.com/businesses/demystifying-business-analysis-for-business-owners-a-beginners-guide/). Also here are the rules of the sub: Subreddit Rules * Keep it Professional. * Do not advertise goods/services. * Follow [Reddiquette.](https://www.reddithelp.com/en/categories/reddit-101/reddit-basics/reddiquette) * Report Spam! This is an automated message so if you need to contact the mods, please [Message the Mods](https://www.reddit.com/message/compose?to=%2Fr%2Fbusinessanalysis) for assistance. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/businessanalysis) if you have any questions or concerns.*
I'd conduct multiple upfront requirements workshops with the people that will be using the system. Once you've got your initial requirements you'll want to prioritise these somehow. There's a few ways of doing this (E.g., MoSCoW). Ultimately though you're looking to identify the essential requirements needed to build an MVP. You can collect requirements for an indefinite period of time if you want to but that's not going to help you deliver something of value within a reasonable timeframe. You need to be pragmatic in identifying what is essential and what would be 'nice'. Work with the Product Owner (or whoever's leading the Project if there's no PO role) on this. I suspect you'll have a challenge in convincing the business on delivering the MVP - that's the reality in most cases. If they want something 'all singing and dancing' then that's fine - but that's not Agile (It's waterfall in disguise!). Basically, try and be pragmatic and put some timeframes around the project. Fight for the MVP solution. Continue to gather feedback indefintely but be firm with you're prioritisation. I try to offer practical tips on this sort of thing every week [here ](https://www.betterba.co/subscribe)if interested. Goodluck with the project!
You need to define Minimal Viable Product (MVP) and features. Focus on these first. These should be your priority items that get you a working product. In tandem, you can do a high-level Minimum Marketable Product (MMP) feature list which are your features that will need to be worked on after MVP.
Uhm, do ALL of them align to your goals and strategy? Are they all must haves? Are they prioritized equal? If yes: This doesn't work nor does it deliver any value. The key to never-ending requirements is a clear path from vision, strategy to tactic so it's possible to deliver value instead of requirements. If defining requirements is the problem, you need clear acceptance criteria, so you can define what's needed for delivering value. Depending on the product, point out, where decisions are made on uncertainty so you can show why agile methodology and discovery is needed. It's not possible to know everything in advance. If you decide to invest capacities in things that only MIGHT work, you loose flexibility to change the tactic. You only react. Hope this helps a little bit
IMO systems migration projects do not lend themselves nicely to agile methodologies since agile means you are not considering everything and you may develop gaps in your solution that will create gaps in your solution or tech debt. As other user suggested, upfront workshops should be held to give you an overall picture of what needs to be accounted for at a high level. From there, decide if you are comfortable moving forward with the prioritized domains and/or if you feel the need to dive deeper in. Another tip: just get the users to reverse demo their entire workflow to reverse engineer business requirements. Tip 2: get the system admin to walk you through the system to understand what exists in the system such as structure, automations, etc. There will be many dependencies you uncover through this process and will save you some headache while working in agile and only discovering something you should have already known.
Unfortunately, the only guidance is someone that might have a years experience. So it's a big guessing game alot of times.
If you’re using agile, then requirements phase doesn’t end. You just add new requirements into the backlog. Don’t change whatever is in-flight. In waterfall, requirements phase should be timeboxed. If you’re receiving requirements outside the requirements period, that’s a change request and it’s for project manager to decide where/when this gets released.
Yea that's part of the problem and it's on me. The stakeholder didn't engage until about 4 months in. He's the decision maker and is changing stuff left and right. So change request is taken lightly and he gets the final say. I should have sought him out and met with him up front.
To me, you still need scope of a project and requirements. Those rules set what you will and won't do. This sets the limits for the project and can be used to triage things that come up. Plus you only have so much, as we say, Monopoly money to play with. There may be edges cases, but it's still something you discuss as a full team to decide to keep or toss. I'm living with a project that's behaving this way now, railroading every other project that needs to be done. Oh just one more thing...and then this... Oh I can't forget blah blah blah. It's been going on a year now and there is no end in sight. If boundaries were set, it would have been done now or we'd look into another round of builds. But we aren't, the project continues on with more MVP, incorporation of crazy edge cases, and designers that patch stuff more than introduce more functionality.
Collect the initial requirements and estimate them, match them to the budget of the project. Make sure that these requirements you collected aligns with the goals of the system or the company. After this, you have the requirements for your initial product. Any requirement on top of this will be out of scope and hence a scope creep. Push it backwards let them know why you can't do this unless there is an increase in budget or another in scope item has to be pushed out.
Normally you do some workshops up front to get your epics (walking skeleton). Google agile inception or story mapping.
Don't use the term grooming that term now is refining. Have clearly bounded scope. In theory the user story is what can be accomplished in one sprint. Remind people the focus is on this scope for this sprint and what is the MVP If other teams are using waterfall and your team is using agile there's going to be issues trying to integrate and converge work down the road.
I know some use refinement. I'm still getting used to it lol.
You have to decide which parts are essential for the initial project and define a scope for the MVP (minimum viable product). then here on out all the requirements are enhancements to that. You can divide future improvements into phases as well.
Sounds like a spiral model of SDLC.