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 up

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 Team The 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

Product Backlog: Should you write everything in user story format?

I like user stories a lot. They help everyone talk the same language and results in a better product. User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. Once I