Well my project has progressed to estimating and prioritising. We have developed good drafts of the User Stories (Requirements) that represent the project. As the project is small, we have drafted all the User Stories required for developers. We organised workshops to introduce the Project, Epics and User Stories, this allowed the team an initial understanding scope. In subsequent workshops we walked through each User Story to understand and refine the detail so they could be estimated. Some observation;
- User Stories written from a business perspective may not allow easy estimation. So some level of restructuring/refining occurs e.g. into functional components. This allows the User Stories to be more effectively estimated by development team.
- User Stories are also refined with system knowledge which factors in system limitations, different design approaches, system options and capability.
- Product owners are engaged as part of this review so that they agree any adjustments and refinements.
- Acceptance criteria is key component of the review and needs to be understood so teams know when the work they do is considered done.
- User Stories are not just defined for development activities, but business process change, testing and acceptance and probably others.
- The iterative refinement of User Stories is built into the framework so there is a level of ongoing refinement.
- The refinement involves many stakeholders from product owners, developers, testers etc. This discipline based refinements make the User Stories much more robust and effective to deliver, while setting the appropriate expectation with product owners of exactly what they are getting.
While working with the team to understand and refine the User Stories, we also start to estimate. Each developer has a set of cards, which are based on Fibonacci numbers (1,2,3,5,8,13 etc.). After User Stories are discussed and refined, each developer estimates what they think it would take to develop. Each estimates is disclosed at the same time, so no developer can influence other estimates. Usually estimates are fairly close and can be quickly rationalised to an agreed number. Where there is broader variation in the estimates, the highest and lowest estimates are discussed. Through this discussion there is an agreement of what the estimate should be, and possibly further refinement of the User Story. The number does not represent effort or function points, it’s just a scale. So based on previous development performance – Velocity, a Scrum Master will know how many points can be achieved in a given Sprint. The velocity for different types of development will be different and therefore the estimates for those respective developments will be different. So 5 points for an online development will not be the same as 5 for ERP enhancement.
Next stage is building of Sprints. A Sprint is period of time a defined team will deliver User Stories. The duration of Sprints will vary based on organisation capability, type of projects, resource capacity tec. A common duration is 4 -6 weeks. In our case, we work on 2 weeks to provide ongoing throughput. Also the number of resources used in the sprint can vary, I believe good practise is about 6 to 10. If you have too many it can impact the effectiveness and nimbleness of the team. As well as estimates for User Stories, there is another essential step, the prioritising User Stories. In our case it Product Owner and PM agreed prioritisation prior to the estimation process.
Observation from estimation process are
- It is a reasonably fast and effective process
- Having all the key people involved and discussing each User Story substantially clarifies what is to be produced
- The card approach makes this process a lot more fun and engages the development team more effectively
- Velocity provides an in-built repository of development performance which increases the confidence of delivery
- Structuring work into Sprints provides a clearer structure for managing the development process
Next blog will be about how all is planned work is actually delivered
- 5 Common User Story Mistakes (agile.dzone.com)
- Agile Hardware Development – The Definition of Done (agileteampros.wordpress.com)
- Agile Development Process (techmytalk.com)