> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/management-workflow/coding-process/software-creation-process.md). # How to do a story Here is a way of dev completing stories. It is not one striaght through process but iterative. * Pick story from backlog, only if it ready and team is within WIP limit * Researching story * Similar stories - look for tests, look for code * Making notes for kickoff * Kick off * * gather stakeholder (ba/testers/ others) * Discuss Stories * Make notes * What is expected, tests to be documented * Answer any queries from the questions from research * Areas that will be affected (DB/performance testing/other apps etc) * Deadlines * Story Champion * Some one who sticks with story from the beginning to the end (or there for the longest) * Point of contact for BA/testers * TODOs in jira * What needs to be done * In table format, two columns: action and done. * When done put tick, or put messsage/action taken, or waiting * Notes in jira * Any notes relatign to the story * any correspondence with stakeholders, that is relevant * files (patches, documentations, examples of api etc) * Anything in code that might affect the story (Current behaviour or issues with future behaviour) * Development * ATDD and TDD * Start with acceptance test * Look for similar tests, or methods already created * When going into classes, doing more complex flows need to TDD * Check that wording of acceptance test is good, everything is logged correctly, notes added (story numbers, links to other tests) * Look to break tests * Refactor prod and test code, make code better for next user or to be able to do the story * Debug when test fails, then solve * Using diagrams * pairing * Comms with BA * Throughout developing the story, there might be decisions that need to be approved by the BA * Add and complete todos in code * instead of getting side tracked, look to write todo comments * mentioning story number ie // TODO: PHO-123 - blah blah * This will help stay focused on passing the test or refactoring * Other projects that need to change, used as libraries * use DEV-SNAPSHOT * inform others who might have a dependency on it * Commiting * Checking changes to see if good * remove unneeded imports, fix styling * Write commit message - story, who worked on it, description of changes * commit on green build, fix other broken areas * Small logical commits * Pushing to repository * Make sure CI build is running * monitor CI build * Fixing builds * locally * after CI failure * Other projects that need to change, repeat the above * Splitting work * During the story, it might be larger than expected, this is when new stories should be created. If there is work that will take more than half a day, put it in another story. Stories should not last more than 3 days. * Before signing off, start the application, and do a quick manual test to see if it is actually working * The end to end test should do this, but this might not be the case * Sign off * What was completed, go through tests * Discuss with tester how to test if not routine * Link acceptance/documentation tests to jira * When done, all todos are done (jira/code), inform analyst to have a look * This may come back with changes to the tests (naming) to improve documentation or logs/req/rsp may not be correct and code changes will need to happen. * This may invovle discussions, as to whether it is appropriate or feasible for the story. * When testers pick this up, then they may need help or clarification from devs who worked on the story * This can happen sometime after the story, so there may be a bit of context switch.