The first step to better estimation is atomization
In agile developing process, user story is a term that we use to define requirements. It is important feature that gap between the management and the development and let them bridge the gap.
However, One of the things that frustrates management most is miscalculating the time to finish user story. When I moved to agile developing, It was one of the hardest thing to do and I had difficulties to estimate how much time I need to finish user story.
As I gained experience and working with one of the best teams in HPE software, I learned to estimate better. Estimation is a process that is being consisted of several crucial components. The basic component is just designing better user stories, and the first part of is automization.
It is hard to estimate user stories that takes several iterations. When a developer is looking on a feature, it can be difficult job to understand all the possible risks - and more important, it is quite easy for a developer to postpone hard issue to the end of the developing process. Do we have issue in back-end API operation? let's deal with it later. Do we have security issues in front-end UI? We will deal with it after we have functional UI. It can be frustrating for the managers when the developers report on good progress in every SCRUM meeting but when the user story is supposed to be completed there are a lot of issues and problems.
My way to deal with it? Atomization. It means to create user stories from the developer's point of view, not only the user. It helps with correct estimation, evaluating risks and allowing raising possible delays and issues. If you doing it right, you are avoiding a lot of mishaps.
When I say that the user stories should be atomized - it means that the user story should be minimized to the extreme. It should be testable, with well defined accept criteria, but it should be very small. If the user story represent functionality that cannot be minimized, You should split it. For example, I usually split my user stories to 4 parts:
- The back-end\middleware API.
- The Front End service and controllers.
- Front end functional UI - just enough for end to end testing.
- Front end final UI - With final approvement from UX, UI and fine tuning.
From pure agile perspective, those are not a "real" user story. they do not follow INVEST guidelines, they do not have really "user" perspective. However, I found it extremely easy to define because they are "developer oriented".
The back-end\Middleware API
The goal of this user story is to provide solid, secured and performance proof API for the other related user stories. Since I am working at TDD mode, The accept criteria for this user story is that the automated testing should pass as expected. If you don't have automated tests, you should describe to the QA the API signatures and let them go wild with the API.
The front end service and controller
It is not important if you work with Angular, knockout.js, Drupal, WordPress etc. In every front end there is a component that communicate with back-end API. This pat accept criteria is also pass the automated tests.
Front end functional UI
The QA or any automated end to end test system will need some UI to work with and test with. In this user story the accept criteria is that the whole functionality suppose to work completely. It can be achieved by human QA or by automated end to end tests. If you have integration tests, one of the acceptance criteria is that the integration automated tests will pass. The UI should be functional, but not pixel perfect.
Front end final UI
This is the pixel perfect phase. The acceptance criteria, is that both the UX and the UI approve the UI completely. In that phase everyone (but especially the design guys) can test the whole functionality from back-end to front-end in demo\dev\integration machine.
Split your user stories as you see fit
This is just an example that works for me in my current project, anyone can divide their user stories as long there is strict and easy to understand acceptance criteria. It is much easier to estimate atomized user stories that are equal or less than one iteration (i.e. sprint) than user story that represent action from user perspective but disregard the developer's perspective.
The estimation is also made easier because the developer know the risks in each phase. If it is new product, or the new interface include a lot of new UI components, phase 4 will take more time. If the back-end require integration components, phase 1 will take more time.
Done is done
Atomizing can be chaotic. If you split the user stories, you can find yourself with a heap of bugs in the end of the last step. Those bugs are from integration issues. If you did not made sure that the back-end API, or the front services are solid, well backed with automated testing and are bullet proof, you will spend a lot of time on fixing integration issues. The most important lesson that I learned in splitting user stories and make sure that every user story is really done.
