If you get wrapped around the axle as to whether this is scrum or not, or whether you're a scrum master or not, you won't be very successful. You're being aske

If you get wrapped around the axle as to whether this is scrum or not, or whether you're a scrum master or not, you won't be very successful. You're being asked to understand and model requirements, and then break that down into features that can be worked on by a team following some sort of iterative development process. While this is not coding, it is certainly engineering. To be successful at that, you'll need to lean on the team for help on this, so you should talk to your team and ask them how they feel about it and any suggestions about how to get it done. You're also being asked to do all the legwork in managing tickets, etc. This is something you should ask your team about. A competent team with decent tooling should be able to carry this sort of thing together. Part of the job is setting expectations with management as to when it is appropriate to interact and when it is profitable to try to steer things. I've found once a quarter is the best expectation to set. This allows a quarterly plan to be created that has buy in from mgmt, and then that can be broken down into 2 or 3 week sprints. A quarter is 91 days, or exactly 13 weeks. If mgmt is expecting to constantly interact, then they need to learn to not drive by looking at the hood of their car, and you might not want to be in that car.