Skip to main content

Scrum release planning: How to involve Juniors & Seniors & people from different background


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.

Technical Knowledge 

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.

Comments

Popular posts from this blog

SCRUM- Who should write a user story

Traditionally user stories (or requirements) were written by Business analysts. They used to prepare big documents after months of study. It was a herculean task. I used to get such UI/Functional specification documents. I have fixed a lot of bugs because I missed few text in such 1000 + pages document. This is not the only interesting part. Some of the requirements were so weird that I often wondered why I am creating the features which no one is going to use. If I had the option I would have recommended a better option. If the BA’s misunderstood some requirements & customers failed to correct those few words in the epic requirement then we will have a nice situation.
In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can upd…

What are the rules of scrum?

A relatively new person to scrum asked me this question last day. My answer to that person was yes. But really does the scrum have any rules? Scrum is a framework which helps us in developing software. It has very few rules and apart from those basic rules rest of them are guidelines like best practices.

Some of the rules 

The roles of Scrum
•Scrum Master - http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html
•Product Owner
•Feature TeamThe PDCA cycle (http://www.theagileschool.com/2012/05/pdca-scrum-or-agile-why-is-it-important.html )  frequent communication about risks (daily)
•Plan – Sprint planning
•Do – Actual engineering sprint – deliver a potential shippable code
•Check – Sprint review
•Act – Retrospective 
The scrum guide @ http://www.scrum.org/Scrum-Guides will be a good guideline for teams/companies planning to start scrum. If you are following the recommendation in these then you are following scrum.
Apart from these rest of the ceremonies and artifacts are there…

PDCA & SCRUM (or Agile); Why is it important?

The PDCA (Plan DO Check Act) cycle was made popular by Dr. W. Edwards Deming. This is a scientific cyclic process which can be used to improve the process (or product). This is cyclic in nature and usually time boxed.

Plan 
This is the first stage of the process. During this step the team discusses the objectives, the process and the clear conditions of exit (conditions of acceptance). This stage sets the measurable and achievable goals for the team.

DO
Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process.

Check
Once the implantation is done team regroups and verifies the output and compares it to the agreed conditions of acceptance decided during the planning phase. The deviation, if any, is noted down.

ACT
If any deviation in planned tasks is observed during the Check stage, a root cause analysis is conducted. Team brainstorms and identifies the changes required to prevent such deviations in future. Team also brainstorms idea…