I have posted previously on AX and Scrum this is just a continuation of my series.
This post shall cover what a story is. A user story is a short description of what is needed. The main purpose of this is to be able to estimate the piece of work.
Below is an actual story i have worked on.
We could (should) have written this different. In scrum they teach you to write it in the perspective of the actor. For example: “As a work order user, I would like to create a work order and submit it to workflow. I would like to get alerts and notifications.”
One thing we like to do in our team is set up Acceptance criteria's (those AC1 2 AC5 that you see in the screenshot). At the end of the day we use it to tell us a story is done.
The next step for use once we have given it sized the story and accepted it into a sprint. We start putting some finer details. We break down the task.
Our comment tasks that we use and to use to indicate a story is done are:
- Functional design – Doesn’t have to be a full functional document to describe every detail. We use this as an agreement document of what is going to be built and helps us think through the solution before we do any development. Sometimes this can be bullet points but it is encourage to at least write up the business requirement and what we are trying to achieve. It should also work through ticking the acceptance criterias too.
- Technical design – A technical document usually involves an ERD (UML diagram). If description of what's been done and describe complex functionality.
- Development – Start coding.
- Functional review – Usually when a developer and another functional person work together and see if they are on the right path. Back and forth till development is done.
- Test cases – Write up test cases. This doesn’t have to wait till development is done. This can be done and sometimes it is good practice to do it before development. Developer knows what to test against and how to test the piece of functionality.
- Unit testing – Now that the developer has finished development and it is checked in to the TEST environment. Someone else can start testing. Developer can fix any bugs/issues etc.
- Functional integration testing – At this stage all the stories are done and a FIT environment is built. We start testing as a whole through. Use another person other than the guy who did the unit testing. Methodically go through the test cases written up. Automated testing and performance testing is done.
- Online help – All forms need online written for them. Any procedure documents etc.
- Release notes – A brief description of the functionality. This is good when we send out our emails to say what has been achieved in the sprint.
- Implementation documentation – This is a document that is updated every sprint. It is a guide for implementers on how to set up the system. What/Why and How?
- User acceptance – Usually when we go through the functionality and present it. This is done regularly but done formally during the sprint review.
The above tasks are pretty comprehensive and allows us to estimate how long a story takes as each task is estimated in hours. This is not set in concrete but this is what we do.
The results you see on a series of posts. The overview contains a flow diagram that was roughly documented as part of the functional design.