Doing release estimation for a team is always tricky especially if the team is new or has a mix of people with different skills or experiences. Traditionally project managers did the estimates and in most of the cases it was under-estimated. Usually the PM takes the help from some subject matter experts before arriving at these estimates. Team will burn the midnight oil (or lamps :D, I hope they didn’t really burn it , there were many occasions when I wanted my PM to be burnt instead. ) But with scrum the estimation is the team’s responsibility. When I talk about this concept I get a lot of questions like the below
- How can a bunch of people with different technical & domain skills estimate?
- How can we trust the estimates from team, they will always over-estimate.
- It is a waste of time, with so many people involved; it will be a never ending exercise.
- The senior folks will do the estimation & juniors will go along with it without asking any questions.
The questions are endless.
Estimates from a group of people are far better than an individual. It is better to have the estimates from the people who are going to develop the product. They will do an estimate by considering their strengths and weakness. If there is a domain/technical knowledge gap then they will be able to discuss and bridge this gap. This looks rosy, a silver bullet for all the estimation problems. Such silver bullet is not produced from vacuum; lot of work has to be done to make this bullet. Many teams find this group estimation very difficult & time consuming especially when they have a sizeable number of new people or junior resources. (I have seen experienced people also failing in this) These teams fail because they were not prepared for such an exercise.
Following are some good practices to prepare your team for release planning
Training Plan for new/junior resources
You should have a training plan for any new resources in team. I suggest that every new team member should execute the regression test cases at least once even if they are developers or testers. This will ensure a common playground when the application features are discussed. Everyone will understand and will contribute positively to the discussions.
For any new feature do the release planning in the following fashion
- Before you start ask the Product Owner to provide a high level overview of the features which are to be estimated.
- Divide your team into sub teams with a mix of Sr. developers, Jr. Developers & QA.
- Assign each sub team one story from the backlog.
- Ask the sub team to breakdown the story into vertical slices.
- This should be done in a time box
- After the time box expires, exchange the notes with other team.
- Review the notes received from other team and add any slices missing from the card
- After the cards are reviewed by all, you can proceed with story pointing.
- It is the job of the scrum master to ensure that everyone speaks up. If the story is really difficult or complex then separate meetings should be set up.
- In one of my team, we used to schedule weekly meetings to discuss the upcoming features. In the first part of the meeting we discussed the story; the later part was reserved for all the technical discussions for the story. We used to discuss about the design patterns, the functions to be changed, the need of database script etc. Usually we identify a lot of unknown, which were duly noted down. Based on our capacity we used to do the spikes on these unknowns and provide the answers in our next design meetings.
You may solve the lack of domain knowledge in this manner.
The technical part is more difficult. It depends on the quality of resources you have. If you have good engineering practices like TDD, BDD then the transition will be fast.
When a techie joins our team we give a session on the business domain & technical aspects of the projects. We do a walkthrough of all the major classes and functions.
In my team we have a buddy system; a junior resource is assigned to experienced person. It is the duty of the Sr. guy to mentor the new resource and bring them up to the speed. The pair is given the complete freedom to choose the methods to achieve this goal. Sometime it could be pair programming sometimes it could be a detailed discussion sessions or anything that works.
The less experienced people might work in a module which they are not familiar but if you have god plan of initiation, do a good release plan & have a good technical practices then the transitions will be easy & new people should pick up the knowledge very easily. They might ask few extra questions & may take few hours more but it will benefit the team. I like this level of discussions and noise; I will be worried if people don’t make much noise or don’t ask any questions.