During my initial career in software development, I was directly jumping to a programming solution without doing problem analysis.
I still remember sometimes I had missed some of the functionalities since I haven’t done the proper analysis.
I and my product owner were having too many discussions.
When I worked with the education team in Tieto, I got the habit of analyzing customer problems. During analysis, I choose to divide the customer problem i.e. requirements into use cases.
I choose to share it with my product owner before starting the coding.
Since then I have been writing the use cases before starting the coding, why? See these benefits.
- You could anticipate whether estimation assigned to a story/work item is correct or not and can raise the flag within the team.
- You could easily break down the work into the small minimum viable product.
- You could get better ideas about use flows like instead using a button in grid row, we could use a toggle button.
- You could create a happy path, unhappy path, edge cases, and alternative flows so that you would not miss any cases or functionalities.
- You could easily track the progress of the story/work item.
- You could give clear updates in daily standups as I worked on use case#1 yesterday and today will finish use cases# 2 and 3.
- You could anticipate the code changes in advance against all cases.
- You could anticipate the blocking dependencies say for example you’ll need an answer from the product owner.
- As a developer, it would help you to write tests against these use cases.
- As developer/QA/PO, you could do functional testing against the use cases.
I would recommend you to go through
In my humble opinion, try to write very lightweight use cases instead of the very descriptive essay.