Analysis Planning

Product owner/manager talk to the customer to understand the scope of the feature request
Define userstories and verify scope of each story with the customer
Plan analysis tickets on the development board of the next sprint for each of the stories
The description of the ticket should describe the entire scope of the story. Give as much info here as possible to reduce confusion later on
Order of the tickets on the board define priority. Higher on the todo-queue means higher prio.

This priorization also takes analysis tickets into account.

Analysis

If the top ticket on the todo-queue is an analysis ticket the dev takes up this ticket and does an analysis of what needs to be done.
If there are still questions/remarks this is the time to ask/make them. If something is unclear go ask the productowner for clarification.
If this opens new questions to the customer the product owner can still ask them here, without any dev time being lost.
During this analysis the dev can already start suggesting (in the analysis ticket) how to split the story into development tickets
During the analysis the description of this ticket can be rewritten by the dev to make it clear. Everything that needs to be done should be again clear from the eventual description of the ticket. Note that it is possible that another dev will pick up the actual implementation of the story. So make sure that the description is adequate
After the analysis is done the story can go to the estimation phase

Estimation

Notify (at least) two other devs of the team that the ticket can be estimated an plan a small meeting (or do it ad-hoc) of about 10 minutes to discuss/estimate the story.
Other devs should quickly read/skim the estimation ticket before going to the estimation
Gather the devs/QA/product owner for the estimation meeting.
During estimation the dev that did the analysis will elaborate on the ticket and voice his concerns/suggested approach
At this point the product owner can also verify that everything is indeed understood correctly.
The rest of the team can still ask questions/make remarks.
This includes QA engineers asking potential questions about how to test/validate the story etc.
Once everything is clear all the non-dev can leave the meeting.

Story Splitting

Since all devs are together now anyway they will discuss how to split the story in sensible implementation tickets.
Each ticket should be individually releasable and deployable. Include feature flags if neccesary
Split them up as best as possible. and take note of which tickets could be parallellised.
When the story is split up as best as possible go over each ticket and make an estimation of how long it will take.
Do this in a planning poker style. Each person chooses a time approximation (trivial: 1-2hours, small: 1/2-1 day, medium: 2-3 days, large: 1week+)
Everyone reveals how long they think the ticket will take. if all 3+ devs are in agreement this is the final estimation for that ticket, go on to the next and repeat for each of the tickets.
If there is no agreement see if someone estimates it way simpler, or way more complex. (more than 1 lvl difference) if person A says its trivial, while another says it will take about a day or 2 there is likely some misunderstanding. Let each person again voice their reasoning why he thinks so little/much time is needed.
After another discussion everyone can vote again (hopefully the estimations are closer together the second time)
If everyone is in a semi-agreement meaning not more than 1 lvl difference an average can be used. if 3 people say it is trivial, while a 4th says it is small feel free to write down the trivial. All else being equal use the higher estimation to create a buffer.
When the estimations are all done, note it down in the description of the userstory and mark the analysis ticket as done.

Development Planning

Now that the analysis is done and the developers have had their say about the estimated time it will take the project manager has a better idea of how much work is going to be needed. Which makes planning the development tickets a lot easier.
Take the analysis ticket that is now marked as done. In the description there should now be a list of tickets each with their aproximate time estimation.
So create an actual ticket for each of them and plan them accordingly adding them to the appropriate sprints (obviously don’t add them to ongoing sprints)
Also make sure to link the newly created tickets to the analysis ticket so the devs can revisit the scope of the entire userstory if needed
At this point a commitment can be made towards the customer as well.

Development

The tickets that we have already estimated and analysed are now in the TODO column.
Pick up the one at the top of the boards and start implementing it.
Make sure to write unittests and integration tests.
When you are done first do a functional test yourself. You don’t want to make a fool out of yourself by having your ticket be sent back by QA.
When you are confident you are finished you create a pull request and mark the ticket as ready for review

Reviewing

When you see a ticket in ready for review pick it up and move it to the review column in the board. Its fine to be critical when reviewing but be constructive. It is fine to mention personal preferences but don’t block a ticket because of it, unless you have great arguments why it is imporant. If that is the case have a discussion with the other dev and try to convince them :p
If you have remarks make them and notify the dev of the ticket that they should do another iteration.
Changes and updates should be committed on top of the current branch in the form of fixup commits (this makes it a lot easier for the reviewer) or new commits
Also verify that the commit history and messages make sense during review. No one likes an ugly git history
When everything looks good notify the dev so that they can rebase/squash their fixup commits and mark the ticket as ready for testing

Functional Validation

When QA sees a ticket in ready for testing they drag it into the testing column and do their validation. If everything is fine, wonderful, QA merges the code into master and the ticket can be resolved.
When an issue is found the ticket is marked as QA found issues and add a comment to the ticket explaining the problem and how to reproduce it. Also adding a i expected this helps a lot.

Merge

If the branch has no conflicts with master QA can simply merge the ticket to master and close it. If there are conflicts one of the devs should first rebase the branch before merging. Make sure that the integration tests run again before actually merging it into master.