I'm new to Agile. I'm currently writing a software that basically does a simulation using real-life objects – for simplicity's sake here's an example:
I have a GUI where I can add two Human Object(s) onto a plane, a Ball Object, and one Human Object. Then I can press a PLAY button to simulate a situation where Human Object A can throw the Ball Object by specifying parameters I can use physics based on Force/Velocity/Direction, and then the Human Object B can catch the ball based on its own position and time while he is walking (where its movement is specified by reading in an input file).
It's a two step phase where I do parameter specification, then pressing play to simulate how those events unfold.
My difficulties reside only for the backend part where I know I need an a) Event Handler, b) Coordinate system infrastructure. But I'm having trouble determining where in my User Stories they should belong?
Right now they sit on its own User Story just written as tasks as "Event Handling." and "XYZ Coordinate System", which I feel is not very well placed.
What I'm trying to understand: If I have the User story:
As a user, I want to be able to be able to add a Human Object to my simulation so that I can have the object interact with the ball
Would my Task List (for specifically back-end stuff) include:
Or should I stick those tasks into a User Story like
As a user, I want to be able to see my objects interact with each other when I press a play button so that I can determine what the status of the objects are after it is done playing
to handle the task of implementing infrastructure of the coordinate system and event handling?
(And to note, in reality outside of the example, I have a lot more objects and back-end processing.)
The direct answer to your question is that the user story you put at the end is probably your best bet for a user story. Implementation tasks are just how your team is going to make that happen. Where it gets messy in complex work like what you are describing is if that user story takes a month to build and you have to break it down.
You want to deliver functionality, even if it isn't the whole package. This may be abusing your example, but where I'd probably start in the case you give is first limit the scope of the user story to simulating those exact objects and interactions: 2 humans and one ball. This takes out a lot of the variability. Now, from a programming standpoint, there is a huge trap here. When you implement it, make sure to do it in a way that those areas can be expanded later without throwing the implementation out and starting over if you can.
Next, if that is too big, I'd probably split the throw and the catch simulation. This is implementing the code in a way that is aligned with the purpose of Agile. If I make Human A throw a ball, I can show that to a user and potentially learn. Maybe we are simulating football and we throw a "prolate spheroid" (the term for the shape of an American football) in a perfect spiral. I show it to the user and he says "No no, we're from Spain, we are simulating an overhead 2-handed throw of a round ball." Now you've learned something critical about the work you've done and the work to be done (the receiver can't catch with their hands).
The specific tool of user stories may or may not be helpful. I could write this last one as "As a sports coach, I would like to simulate a throw-in so I can experiment with different techniques." That contains a lot of convenient information for me. In particular, user stories are most valuable in places where you are trying to understand your user's needs better. However, if you feel you understand them well enough, "Simulate throw" is a perfectly adequate backlog item.