Random Thought – User story sizing

User story sizing is based on relative sizing. It means story-A is approximately twice big as of story-B and your big is different from mine.  It means there is no standard way of saying that how much resources (skill, time, people, coordination effort, etc.)  are needed to complete a story.

But there is a catch. As we start working together, slowly your big and mine big start to converge. But it requires a close working relationship. It also means that team-1 big might be different from team-2 big, so we can’t compare team-1 and team-2 on the basis of the number of story points completed in a sprint even if team size, type of work, the skill set of team members, distribution, and other thigs are same.

To compare teams, we need to look into their velocity trend with annotated information around context for each team (number of team members, type of work, distribution of team members, the skill set of team members, the dependency of stories, availability of team members, the structure of stories, etc.). Also, every spike (and dip as well) in trend line should be annotated with reasoning (e.g. team lost few members during sprint five).

Now, let’s back to assigning story points to each story. We as human beings are terrible at sizing, especially if size is either big or small. So any scale which is to be used for sizing user story should be widely spaced and space between two pin points must keep on increasing as size increases (assuming we will not estimate the small work). Fibonacci series fit into this requirement. It is suggested that every team member develops some mental model to start with for sizing purpose. I have developed mine own model and love to share:

Story Point	Mental Model	Remark
1		Story is too small to estimate, it must be combined with a similar story.
2		Story is small but acceptable to work with.
3		Story is of good size and I can complete the work in a couple of days.
5		Story is again good size but may touch upper limit of my capacity to complete in a couple of days.
8		Story is big enough. I need to split into smaller ones so I can complete the committed work in a couple of days.
13		Story is definably big and must to be split into smaller ones. Are we going to the moon?
21		Oh my God! It is not a story. It is an intergalactic ship.

On the basis of this mental model, I have also created planning poker cards which are available at https://github.com/tusjain/agileanswer/blob/master/PlanningPoker/PlanningPoker.pdf under common creative license.

Agile fable: Agile transformation

You might have come across the fable in which ant work hard but due to the burden of organizational hierarchy and desire for reports destroyed the organization.

Every day, a small Ant arrived at work early and starting work immediately, she produced a lot and she was happy. The boss, a lion, was surprised to see that the ant was working without supervision. He thought if the ant can produce so much without supervision, wouldn’t she produce more if she had a supervisor!

So the lion recruited a cockroach who had extensive experience as a supervisor and who was famous for writing excellent reports. The cockroach’s first decision was to set up a clocking in attendance system. He also needed a secretary to help him write and type his reports. He recruited a spider who managed the archives and monitored all phone calls.

The Lion was delighted with the cockroach’s report and asked him to produce graphs to describe production rates and analyze trends so that he could use them for presentations at board meetings. So the cockroach had to buy a new computer and a laser printer and recruit a fly to manage the IT department. The Ant, who had been once so productive and relaxed, hated this new plethora of paperwork and meetings which used up most of her time.

The lion came to the conclusion that it was high time to nominate a person in charge of the department where the ant worked. The position was given to the Cicada whose first decision was to buy a carpet and an ergonomic chair for his office. The new person in charge, the cicada, also needed a computer and a personal assistant, whom he had brought from his previous department to help him prepare a work and budget control strategic optimization plan.

The department where the ant works is now a sad place, where nobody laughs anymore and everybody has become upset. It was at that time the cicada convinced the boss, the Lion, to start a climatic study of the office environment. Having reviewed the charges of running the ant’s department, the lion found out that the production was much less than before so he recruited the Owl, a prestigious and renowned consultant to carry out an audit and suggest solutions. The Owl spent 3 months in the department and came out with an enormous report, in several volumes, that concluded that ” The Department is overstaffed..”

Guess who the lion fired first?

The Ant of course “Because she showed the lack of motivation and had a negative attitude.

Now let’s flip the organization and its growth in the Agile way of working where the role of managers, HR and any other person/entity who are not value contributor is constantly challenged.

Every day, small Worker Ants arrived at work early, start work immediately, Ants produced a lot, and they were happy. The boss, a Lion, was surprised to see that the Ants were working without supervision. He thought if the Ants can produce so much without supervision, wouldn’t they produce more if they had a supervisor! He also heard there is something called the Agile organization. He thought of trying it and hired an Agile coach to grow the organization is the Agile way. Lion hired Agile coach Rabbit. On the first day of the assignment, Rabbit decided to talk to Ants to understand the nature of work and to understand ground reality. Lion was surprised, as he expected that Rabbit will talk to him first, after all, he is the boss but he kept his silence and decided to observe and learn. After talking to Ants, Rabbit was in Lion’s office and started his interview process. Rabbit’s talk was mainly centered on - what does Lion want from the organization, what is his vision, and what is the purpose of the organization. 

After talking to many people in the organization, Rabbit came with a high-level plan. Strangely, the opening statement of plan stating that it will change as new Information is discovered. This plan has put a lot of onus on Ants to manage themselves while Lion’s, other bosses and supporting departments’ role was limited to providing the environment and resources so Ants can manage themselves.

HR and Finance departments were furious after studying the plan – no concrete dates, metrics, very little control. Rabbit was summoned to explain the plan to bosses of the organization. In his presentation, Rabbit patiently answered the questions raised by bosses who were feeling that they would lose control if Rabbit’s plan is implemented. To sell his plan, Rabbit employed very simple strategy; he leaked the details of his presentation to almost every participant and incorporated their feedback without compromising the Agile way of working. No surprises during the presentation.

Few of the bosses agreed to do small experiments in their fiefdom to try Agile way of working as Rabbit’s proposal was promising better outcome in medium to long term.

In the meantime, Rabbit also spoke with Ants and took them in confidence. The Ants were happy as their views were also taken into consideration.

Rabbit created a representative team of Ants to demonstrate the power of the Agile way of working. To conduct this experiment, he asked all of the executives and other Ants who were not part of the experiment to observe (just like kids in zoo watches the animals – just watch do not interfere). Rabbit volunteered to provide help to anyone if someone wants to set up a similar experiment. Initially, people were skeptical but as benefits of self-organizing, manager-less team started to become clear as continuous improvement in effectiveness and outcome started to flow out, other teams and executives started to reach Rabbit for help set up the Agile teams.

To support new teams in the Agile way of working, Rabbit asked Ants and existing managers if someone is interested in training and coaching and also started to hire new talent from outside with active involvement of HR.

Lion is a person of numbers. After the initial dip, numbers were trending in the positive zone. Lion was convinced that he betted on the right side. He was gung ho and wanted to roll out the Agile transformation across the organization like the big bang. Rabbit jumped in and argued to slow and steady approach like directed evolution.

We as a DevTeam

DevTeam consists of generalists specialists (T-shaped skill set) who can perform all work to create product increment as envisioned in the Sprint Goal. The size of DevTeam is 6±3. There is only one role in a DevTeam – Developer. Each member of DevTeam may have a specialization (say QA, front end, back end, database, etc.) but everyone is responsible to achieve the sprint goal. There are no sub-teams within DevTeam. DevTeam members follow good engineering practices. DevTeam members self-organize to achieve the sprint goal. DevTeam is a long running team and members are full time allocated to it. All of DevTeam members follow same norms and rules.

As a DevTeam, we own Sprint Backlog. During Sprint Planning Meeting, devTeam negotiates with Product Owner to keep its commitment for the sprint. Sprint Backlog represents the commitment of devTeam for a sprint. DevTeam members participate in Daily Standup and share their work and impediment if any. DevTeam is responsible to deliver product increment at the end of the sprint. DevTeam presents items to PO as soon as acceptance criteria is met. DevTeam members collaborate to complete the work. DevTeam only accepts the work as envisioned in the sprint backlog.

As a DevTeam, we participate in scrum ceremonies.  DevTeam actively participates in refinement activities to keep Product Backlog healthy. DevTeam estimates PBIs. DevTeam evaluates the technical feasibility of PBIs. DevTeam is responsible for all work to be done to deliver as committed in the Sprint Planning Meeting (in the form of Sprint Backlog). DevTeam participates in Sprint Review ceremony to collect feedback from stakeholders. DevTeam conducts Retrospective in the end of each Sprint with PO and SM to reflect on self. DevTeam helps PO to conduct Demo.

As a DevTeam, we strive for automation to keep effectiveness and productivity (velocity) curve upward. DevTeam adopts Agile engineering practices to keep the quality of product high. DevTeam members strive to learn new tools, techniques, technologies, and skills to develop T-shaped skill set. DevTeam members work closely with PO and SM to deliver consistently and effectively.

As a DevTeam we strive to deliver value with sustainable pace. DevTeam remains in conversation with PO throughout a sprint to get clarification on the Sprint Backlog Items. DevTeam has the clear understanding of Sprint Goal. DevTeam not only focuses on HOW but also knows WHY and WHAT. DevTeam is responsible for continuous delivery of valuable outcome. DevTeam is empowered to make the decision about the HOW part to complete the work as listed in Sprint Backlog. DevTeam manages information radiators. DevTeam continuously communicates with users.

As a DevTeam, we continuously educate ourselves and share learnings with technical, Lean, Agile and Scrum communities. We organize and participate in technical, Lean, Agile, and scrum oriented community events to facilitate understanding of technical, Lean, Agile, and scrum values and principles.

I as a Product Owner

As a Product Owner, I am responsible for Product Vision and its continuous evolution. I may not know everything about the product but I know, from where to get that information and how to manage competing stakeholders for limited resources and even manage conflicting views of stakeholders about the product. I am “go-to” person for product domain. I have business analysis skills. I negotiate priorities, scope, funding, and schedule. I own product roadmap as well as Product Backlog.

As a Product Owner, I do not drive technological decisions but understand and appreciate devTeam’s technical skills. I incorporate the technical wisdom of devTeam in Product Backlog’s prioritization in addition of stakeholders’ vision and wishes. I communicate WHY and WHAT of product so the Product Backlog Items. I share product vision with devTeam. I define Acceptance Criteria in collaboration with devTeam for every PBI.

As a Product Owner, I actively participate in scrum ceremonies. I lead Product Backlog Refinement effort with devTeam as well as stakeholders. During Sprint Planning Meeting, I offer Product Backlog Items to devTeam to be developed in current Sprint. I bring in subject matter expert o answer any query by devTeam. I only offer PBIs which are INVEST-able during part one of Sprint Planning meeting. I define Sprint Goal and convey the same to the team before or during sprint planning meeting. I ensure that I am always available to devTeam during Sprint. I accept PBIs during sprint as offered to me by devTeam provided they meet Acceptance Criteria. I have authority to reject any work performed during sprint. I can terminate sprint mid-way. I decide the content of demonstration of increment in collaboration of devTeam and actively participate in the same. I participate with devTeam to split PBIs. I don’t direct the team on how to perform its job. I drive release-planning effort with stakeholders and devTeam. I help the team to remove impediments.

As a Product Owner, I engage with stakeholders on the continuous basis to elaborate PBIs and create new ones. I interact with stakeholders to assign Business Value and prioritize PBIs. I utilize various techniques (Story Map, Impact Map, budgeting of story point to different stakeholders, and other techniques) to reach Minimum Viable Product, assignment of Business value, and prioritization of PBIs. I keep Product Backlog healthy – two to three sprint worth of stories are INVEST-able and prioritized.

As a Product owner, I continuously educate myself and share my learnings with Lean, Agile and Scrum communities. I organize and participate in Lean, Agile, and scrum oriented community events to facilitate understanding of Lean, Agile, and scrum values and principles.

I as a Scrum Master

As a Scrum Master, I assume administrative, coaching, and leadership roles to make Lean, Agile and Scrum successful. I help the team understand and embrace Lean Agile Scrum values and principles to develop into self-organizing teams and to produce valuable outcomes at a sustainable pace.  I assess the team’s knowledge of Lean, Agile, & scrum, and fill in the skills gap through training and coaching.  I serve as keeper of scrum framework, “holding space” for the team. I explore Agile and scrum tools and share my learnings with the team. I encourage teams to share their lessons learned and learn from others using various tools and techniques; e.g. Lean Coffee, Open Space, Tech Talks, etc. I help develop and maintain communities of practice to foster learnings and skill development.  I encourage teams to explore and embrace automation to boost productivity.

As a Scrum Master, I shield teams from interruptions to optimize the outcome. I mediate the general conflict of goals between devTeams (high quality) and Product Owner (more features).  I protect teams from external disturbances during sprints to keep them focused on deploying incremental value to our end customers. I help teams balance proactive activities with immediate goals. I ask open questions to foster communications and exploration of Why and What. I help teams become transparent in communications, practices, and behavior to foster trust. I encourage teams to bring out hidden problems and conflicts and then help to resolve them in benefit of increased trust and transparency.

As a Scrum Master, I facilitate effective Scrum ceremonies. I ensure all team members participate in daily stand-ups to share their respective work and decide how they can help each other with removing impediments. I help the Product Owners and Scrum team with refining the Feature/Product Backlog on a continuous basis to prioritize the Team Backlog Items for Sprint Planning Meetings.  During Sprint Planning Meetings, I ensure teams make commitments based on their capacity. I facilitate Sprint Review Meetings to collect feedback from the wider audience to continuously improve. I encourage teams to remain honest and positive during Retrospectives and to respect to gain trust the proceedings among team members only. I ensure that purpose of Retrospective is learning and improvement, not finger pointing and performance review. I help teams demonstrate the outcome of Sprints to the wider audience to spread the positive word about the team. 

As Scrum Master, I help Product Owners develop a positive rapport with their team and accept him/her as a part of the family. I encourage collaboration between devTeams and Product Owners.  I help the Product Owner interact with stakeholders to develop a collaborative relationship that produces valuable outcomes. I help the Product Owner explore different tools and techniques to discover the Business value of Feature/Product Backlog Items. I encourage Product Owners to interact with stakeholders on a continuous basis to refine and prioritize the Feature/Product Backlog.   I assist the product owner with prioritizing the Feature/Product backlog items.  I help the PO and devTeam develop and evolve Definition of Ready, Definition of Done, and Acceptance Criteria. I help the Product owner develop Sprint Goals and help the Scrum team achieve the same during sprint planning. I provide feedback to the Scrum teams on how to improve. I also ensure that improvement areas identified during retrospectives are captured and tracked in future sprints.

As a Scrum Master, I know when to step back and let the team learn from its own experience – successes and mistakes. I am available to the team for expert advice around scrum, and agile. I work as an advocate for the team in the organization. I certainly do not work as scrum police.  I do Gemba walk and encourage stakeholders to do the same.

As a Scrum Master, I continuously educate myself and share my learnings with Lean, Agile, and Scrum communities. I organize and participate in Agile and scrum oriented community events.