As the maintainer of a very small project (probably only 1000 users at its peak), a non-technical person would have been able to help me a lot. Because it was a one-person only affair, I had only so much time. I probably spent half of it writing and updating documentation, and building and testing installs. I ended up having very little time to code and since there were features that I absolutely needed for
me, I often just jammed them in as best I could. Just having time to concentrate only on code would have helped me a lot. Also, it might sound strange, but if you want a project to gain traction outside of your little world you need marketing. I would have loved to have someone who could write a blog post or two explaining why the project was different than all of the other similar ones around. Doubling or trebling the user base may have attracted another programmer to help with the technical side. The website I built essentially contained only the documentation and while I feel happy with the quality of that documentation, it absolutely lacked anything that would attract new users. Building a screencast showing the killer features would also have been incredibly useful. It was all on my TODO list, but I just lacked time to do it because I barely had time to code the features I wanted.
As you mention, user interface spikes would have been fantastic and saved me huge amounts of time in experimentation.
The thing on your list which I personally would not have found useful Planning Poker. I actually did make sprints and wrote stories and even tracked my velocity. But in the end, you wind up doing demand-based work. Like I said, I wrote the system for me and there were just things I needed done. Those things took top priority no matter what. And with a lack of time, I very rarely got off that list. Even in a large project, I don't think you are going to get much different: coders are in it for scratching their own itch. They will self-prioritise their work and there won't be too much difficulty coordinating it.