I have previously [asked a question on PM][1], which was not well focused, but I still received some useful tips. I do plan on putting some of the notions in front of my manager, but I would like to re-approach our issues here to see if I can't get any more insight.

I work for a mid-sized American company (300ish) on a very small, not officially/organizationally recognized development team (3). Only one of us has a degree in CS (and it isn't me). Our manager is an manufacturing engineer and has negligible experience programming, designing software, or managing a development team (except for the past two years of our 'covert developing'). On top of this, our developer with a CS degree tends to work on projects solo, separate from the other two of us.

We have an *insane* amount of projects our manager is looking to achieve. Essentially he is hoping to digitize most of our Quality & Inspection processes & paperwork, all the way to semi-automating our PPAP/PFMEA documentation. Frankly it is all way more than is chew-able by such a small, inexperienced team (in any sort of respectable time frame), in my opinion, but I admittedly tend to have a 'glass half-empty' attitude. So far our extended time frame hasn't been an serious issue to our company's President. Half of the projects are very large... our current project has more or less taken up about 70% of overall work-time for two of our developers, and has taken 2 years to develop, and still going (we had to restart the architecture and include unit-tests because we didn't know what we were doing when we started).

Now, our manager (who, to his credit spends a lot of time reading on relevant subject matter to try and understand our position as developers better) wants to try and work under a Scrum framework. I have taken on the role of Scrum-Master, our manager as Product-Owner, and of course the other two developers are... developers. Other mgmt. and our President would be the 'shareholders'.

My main issues that I am struggling with, and unsure how to approach are:

 - Our 1 'team' actually consists of two separate development teams
   working on unrelated projects (mentioned in second paragraph) and either team can, currently, get our priorities changed independent of the other team's priorities as well. This seems like it should be 2 separate scrum teams but our manager/PO does not have the time for that, and I don't think I have the mental energy for it, currently. Also, how are we supposed to be accountable as a team for separately developed projects?
 - Projects are all essentially interwoven into the same 'suite' and our
   projects kind of have blurred borders/edges.
 - Even if we break projects into hard-defined boundaries... the
   projects are still quite large and our product backlog could be too
   much to navigate if it is fully populated
 - Fully and accurately populating the product backlog seems daunting, as
   often times 'case-scenarios' are often overlooked by shareholders in
   favor of 'the ideal interaction' or they state outcome but struggle
   to define how to get that outcome even on paper. Sometimes processes get such a vague description such as : "The quality tech would look up the relevant specification and make sure the document conforms"... which you can't turn into programmable logic on its own, we aren't making magical PDF parsers.
 - More on the previous point: Getting vague, generalized process outcomes from shareholders has required us to go and talk to individual employees that actually do the paperwork, often times the nuances in their process will slightly deviate the generalized mind's-eye picture of the shareholders, which then often triggers long, grueling conversations where we as the developers are just trying to get the shareholders to understand *what* we need to know and *why* we need to know it... this seems incredibly anti-Scrum and I don't see how we are supposed to essentially design an enterprise-level software-suite if we have to re-explain why we need to understand case-scenarios and the nuanced details of the process every time we outline a new software behavior. *Is there a way I can get non-programmers to understand our needs better? Especially when I have a hard time outlining our needs because we are trying to digitize processes that often rely on 'tribal knowledge'*
 - We lack personnel to be able to handle documentation, training, and
   maintenance (we often have to drop development work to handle these
   "fires" as they come up)


  [1]: https://pm.stackexchange.com/questions/24475/software-dev-team-managing-task-across-multiple-projects-in-a-manufacturing-pla