Improving User Story Estimate
Consider the following factors while estimating stories.
Complexity: Consider the complexity of the story.
Risk: Consider the team’s inexperience with developing this story.
Implementation: Consider the implementation factors.
Deployment: Consider the deployment requirements.
Interdependencies: Consider other outside issues.
Who should be involved in story Point estimation?
All team members who are responsible for getting a story done should ideally be part of the estimation.
Advantages of using story points for estimating work.
Story points are a measure of relative size and complexity.
Story points are unitless, meaning as a scale, they are only valuable to compare against each other within the same team.
Estimating in story points allows/encourages everyone, including business people to participate in the estimation process (using Planning Poker).
Estimating in story points is fast and easy.
Story points initiate high-level discussions about everything that is involved in a project.
Earned points can be used to generate the teams’ velocity which can be used to predict future work capacity.
Steps to estimate stories.
For each story to be sized, do the following as a team (Product Owner, Scrum Master & Team member).
1. Identify base stories.
Identify one or multiple bases or reference stories against which you would do relative sizing of the backlog. This story is picked from the current product backlog or a different story that we have done earlier. But what is important is the understanding of this story is the same among everyone on the team. The team should be confident of this base story.
2. Talk through the detailed requirements
The Product Owner will answer questions and provide an explanation about what exactly this story entails.
3. Discuss and note down points.
These can be bullet points on the story card or text in the “notes” section of a tool. This is best done by Scrum Master who can add these details as and when discussions are on.
4. Raise questions if any
During the discussion, the question may arise and must be clarified at the same time, Such as:
Requirement: Any doubt about the story requirement? Raise an alert. Ask product owner to give more clarity.
Technical Feasibility: Can a story be delivered using current technology? Any unforeseen technical challenges must be surfaced.
Acceptance Criteria: Team must clarify the checklist to be fulfilled to mark the story as accepted.
Dependency: Does this story have external dependencies? If yes, that must be understood and resolved quickly.
Expertise: Do we have enough skills to deliver the story? The team must have internal skills to deliver the story otherwise delivery might be delayed or not done properly.
5. Agree upon estimated size.
Every team member must agree upon the estimated size decided on a story.
When estimating with story points, most teams use a predefined set of values that does not include every possible number. For example, teams commonly use a Fibonacci sequence (1, 2, 3, 5, 8, 13, …)
By intentionally leaving some numbers out of the set of acceptable estimates, teams avoid bogging down in discussions of, for example, 15 versus 16. Estimating to that level of precision would be extremely difficult and time-consuming, and most likely not even possible.
For accurate planning and estimating, teams need to understand that their job is not to put an estimate on a product backlog item. Their job is to put the story in the right bucket. Yes, I know that in both cases someone grabs a pen and writes a number on a story card. But the goal is to find a number (a bucket) just large enough to hold the whole story.
When estimating, ask the team to picture a set of buckets in front of them labeled 1, 2, 3, 5, 8, 13, and so on (or whatever sequence it uses). And then ask them to picture themselves throwing story cards into the buckets.
This helps team members move away from the feeling that estimates need to be perfect and precise. They do not. Product backlog items merely need to be “thrown” into the right bucket.
In Retrospective Reviewing past work
To make improvements in the next story in terms of sizing
Embracing the learning of “WHY” things went wrong.
Here is something we do often, and we agree that is a 5. When we get some ting new how is it compare to the thing we usually do?
Do not connect the story point to any bonus/benefit patten.
STORY ESTIMATION TIPS
Consideration when estimating User Stories:
Use at least four values during the session. There is the law of diminishing returns to consider, but if there are not enough values then unlike things will get clumped together. For example: if you are using the Fibonacci series to conduct story estimation for a two-week sprint, use at least 1, 2, 3, and 5.
Give your team an out if they just do not know. So, include infinity or at least a high number.
Let the team doing the work conduct the story estimation before they commit. You may have conducted story estimation from a release planning exercise, but you should re-estimate the work during iteration planning just before the team commits. Even a day later there may be new information that changes the estimate from yesterday.
Everyone on the team gives an estimate. This gives an opportunity to discuss gaps and make sure different points of view are covered.
Set a maximum story/feature/epic size based on the time boundaries. If you are portfolio planning and your time horizon is infinite, ignore this tip. In all other cases, break work up to meet the time boundary.
No Zeros. Just discussing the work takes time, so if you find you have a lot of small stories or tasks, try clumping them together and then estimate.
No averages or numbers are not on the scale. Story estimation is a way of educating and informing decisions. Get the team on board.
Break up items that exceed the maximum. If you get infinity or something too large for your time boundary, add risk mitigation or spikes to gain more understanding.
No distractions during story estimation. There is nothing worse than the lead developer playing on his cell phone during the discussion only to ask for a re-cap before he can show his card.
No bribes. Bribing by the technical team, product owner or scrum master undermines the whole process and can lead to saw tooth release burndowns.
Product manager: - Less of a role but more of a responsibility identifies the customer need and the larger business objectives that a product or feature will fulfill.
articulates what success looks like for a product.
rallies a team to turn that vision into a reality.
Product Manager Responsibilities: -
Specific responsibilities vary depending on the size of the organization.
Broadly speaking, though, a good product manager will spend his or her time on a handful of tasks.
Understanding and representing user needs. Listen to your customers.
Monitoring the market and developing competitive analyses.
Defining a vision for a product.
Obsessed on understanding the customers need and finding a solution (don’t be a male gynecologist)
Aligning stakeholders around the vision for the product.
Prioritizing product features/Epics and capabilities.
Creating a shared brain across larger teams to empower independent decision-making.
Watch the competitions (every time the competitor ships a product think of it as UAT)
Always be a student of the client’s needs, it is a mindset
Product Manager vs Product Owner
While a product manager defines the direction of the product through research, vision-setting, alignment, and prioritization, the product owner should work more closely with the development team to execute against the goals that the product manager helps to define.
Product Owner
Works with internal stakeholders
Helps teams execute on a shared vision
Outlines the plan for achieving success
Owns team backlog and fulfillment work
Involved in day-to-day activities
Product Manager
Works with outside stakeholders
Helps to define the product vision
Outlines what success looks like
Owns vision, marketing, ROI
Works at a conceptual level
If the team is doing Scrum but does not have a product manager, then the product owner often ends up taking on some of the product manager’s responsibilities.
Best practices and tips for being a great product manager.
Prioritize Ruthlessly
Empower your team to make their own decisions.
Learn to influence without authority.
