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
Agile Use Cases in Four Steps by Matt Terski
In my humble opinion, try to write very lightweight use cases instead of the very descriptive essay.
