Why Estimate In Story Points

This post outlines the key points in favor of estimating user stories in story points. These include:

• Story points help drive cross-functional behavior
• Story point estimates do not decay
• Story points are a pure measure of size
• Estimating in story points is typically faster
• My ideal days are not your ideal days

  

Story points help drive cross-functional behavior

Agile teams include members from all disciplines necessary to build the product, including programmers, testers, product managers, usability designers, analysts, database engineers, and so on.

Estimate in story point presents a single number that represents all of the work for the whole team. Thus Estimating in story points can help teams learn to work cross-functionally.

On the other hand Estimating ideal days,  often involves specialty groups estimating how long "their part" of a story will take and then summing these sub-estimates.

For example, the programmers may conclude that they need three ideal days, the database engineer needs one, and the tester needs two. An estimate of six ideal days is then assigned to the story.

This small difference in how the discussions about a story take place (to provide a single story point) have an ongoing impact on how the story is developed.

Story Point Estimates Do Not Decay Or Has Longer Shelf Life

An estimate expressed in story points has a longer shelf life than an estimate in ideal days.

An estimate in ideal days can change based on the team's experience with the technology, the domain, and themselves, among other factors.

To see why, suppose a programmer is learning a new language and is asked how long it will take to program a small application. His answer may be five days.

Now, jump forward a few months and ask the same programmer how long it will take to develop an application that is of exactly the same size and complexity.

His answer may be one day because he has become more skilled in the language.

We have a problem now because at two different times, even the applications are exactly the same size, yet they have been estimated differently.

We would like to think that measuring velocity over time would correct or account for this problem. It won't. Instead, we'll see a consistent velocity even though more work is being done. Suppose this programmer is the only person

on the team and that he is working in one week iterations. The first time he develops the application, he has estimated it will take five ideal days. Let's suppose he's in an environment where a calendar day equals an ideal day. He then starts this application on the first day of the iteration and finishes it on the fifth. He has a velocity of five for that iteration. Then, a few months later, because he estimates a similarly-sized application as one ideal day, he will complete five of them in an iteration. His velocity is again five, even though he did five times as much as work as before.

For some projects, especially those adopting new technologies or on which the team is new to the domain, this can be a consideration. Note that both story point and ideal day estimates will need to be updated if the size of an effort changes based on the development of a framework, for example. However, only ideal day estimates need to change when the team the team becomes better at something.

Story Points Are a Pure Measure Of Size

Story points are a pure measure of size. Ideal days are not. Ideal days may be used as a measure of size, but with some deficiencies.

As noted in the preceding section, an estimate in ideal days will change as a developer's proficiency changes. This does not happen with story points—the size is what it is and doesn't change. That is a desirable attribute of any measure of size.

Estimating in Story Points Is Typically Faster

Teams that estimate in story points seem to do so more quickly than teams that estimate in ideal days.

In order to estimate many stories it is necessary to have a very high-level design discussion about the story: Would we implement this in  the database? Can we re-use the user interface? How will this impact the middle tier? are all questions that come up at one time or another. My experience is that teams estimating in ideal days have a tendency to take these discussions a little deeper than do teams estimating in story points.

The difference is presumably because when estimating in ideal days it is easier to  think about the individual tasks necessary to develop a story, rather than thinking in terms of the size of the story relative to other stories.

My Ideal Days Are Not Your Ideal Days

Suppose two runners, one fast and one slow, are standing at the start of a trail. Each can see the whole course of the trail and they can agree that it is 1 kilometer.

They can compare it to another trail they've each run and agree that it is about half the length of that other trail. Their discussions of trail size (really distance in this case) are meaningful.

Suppose instead of discussing the length of the trails these two runners discussed the time it took to run the trails. The fast runner might say, "This is a six minute trail," to which the slow runner would respond, "No, it's at least a ten minute trail." Each would be right, of course, but they would have no way of settling their differences other than agreeing to always discuss trails in terms of how long one of them (or some other runner) would take to run the trail.

This same problem exists with ideal days. You may think you can completely  develop a particular user story in three ideal days. I think I can do it in five days. We're both probably right. How can we come to an agreement? We might choose to put your estimate on it because we think you'll be the one to do the work. But that might be a mistake because by the time we actually do the work you may be too busy and  someone else maybe doing it. And I'll be late because it's estimated at three days for you but will take me five.

What most teams do is ignore the issue. This is acceptable if all developers are of approximately the same skill or if programmers always work in pairs, which helps balance out extreme differences in productivity.

http://www.deltamatrix.com/agile-estimation

Happy Blogging!!!!

Regards,

Arun Manglick

---

本メールおよび添付ファイルは、機密情報を含んでいる可能性があります。そのため、宛先人以外の方による利用は認められておりません。宛先人以外の方による本メールの公表・複写・転用等は厳禁であり、違法となることがあります。万が一、本メールを宛先人以外の方が受信された場合は、お手数ですが、直ちに発信人にお知らせいただくとともに、本メールを削除するようお願いいたします。

The contents of this email and any attachments may include confidential information. Therefore, they may not be disclosed to, used by, or copied in any way by anyone other than the intended recipient and any such disclosure, use or copy can be treated as illegal. In the case this email is sent to you in error, please inform the sender and delete this email.

Risk Management in Agile

Primarily Risk is something that may occur and cause unexpected or unanticipated outcomes.

Traditional project management applies full-blown Risk Management techniques and recommend a full-blown risk register to monitor for managing and controlling risks.

However there is no definite consensus on the need for risk management within the Agile method.

In many of my classes, participants ask how Scrum and Agile address risk management. Some are concerned that Agile or Scrum completely ignore risk management.

Here is the rationale. First, a great deal of explicit risk management becomes unnecessary when a project uses an agile approach. The short iterations, single-minded focus on working software, heavy emphasis on automated tests, and frequent customer deliveries help teams avoid the biggest risk most projects face—that of eventually delivering nothing. So, it is not surprising that many agile projects forgo any form of explicit risk management

This has led many to believe that risk management is irrelevant in an iterative model, rather manage risk & issues through the natural sprint progression.

Because of this, managing risks may not seem to fit naturally into the Agile context.

However risk can be undertaken in Agile also without any formal risk management, may be preferably thru simple techniques: 

• Simple Risk Register
• Simple Risk Burn-down chart

 Simple Risk Register

Below are the attributes to keep risk monitoring thru simple risk register.

Risk register must be made available for the team so that it can be managed and monitored collaboratively. 

• Description of risk: A one- or two-line overview of the risk. It should be simple and easy to comprehend.
• Date identified: Date when the risk was identified.
• Likelihood: Estimated probability of occurrence of the risk.
• Severity: The severity of the risk is assessed based on impact of the undesired outcome.
• Priority (optional): This could be either given an independent value or set as a product of likelihood and severity (above). A high-severity risk with a high likelihood should receive more importance than a high-severity risk with a low likelihood.
• Owner: The person who manages, controls, and takes action in response to the risk.
• Action: The response defined to manage/control the risk.
• Status: Indicates whether the risk is open or closed or being monitored.

At every sprint meeting, the risk register must be reviewed and updated with any new information obtained over the sprint.

This way risk management becomes an integral part of Agile.

Risk Burn-down Chart

Another interesting technique, to managed and controlled risk is thru Risk Burn-down Chart (Originally introduced by John Brothers in The Agile Times in 2004)

In essence, the burn-down chart represents the status of the risk across the iterations.

Similar to other burn-down charts, the ideal burn-down would be a linear decrease of consolidated risk exposure over the sprints.

Risk Exposure is collected into a table similar to a risk register as below. 

• Risk: Description of the risk in a few lines.
• Probability: Likelihood of the risk.
• Size of loss: Amount of time lost should the risk occur. This could be represented in days or story points.
• Exposure: This is computed as a product of the probability and size of loss (above).

 An example is shown below. The consolidated risk exposure is shown in the final row of the risk register.

This consolidated risk register is reevaluated at every sprint meeting; its values are adjusted based on the current assessment of the existing and new risks.

Summary:

Above are two of the bare-minimum approaches that are effective in Agile. They're simple to manage and align with the iterative process.

Adopting one of these is critical to having a proactive risk management approach.

Regards,

Arun Manglick

Agile Estimation

First time, putting this link directly. as this post does not require references from multiple sources .. 

http://www.deltamatrix.com/agile-estimation


Regards,
Arun Manglick

Sprint Retrospective Meeting - Facts & Rules

Source:  Agile Project Management with Scrum by Ken Schwaber

Duration:

1.     Time-boxed to 03 Hours (Three Hrs).

2.     Occurs after Sprint Review & Before Next Sprint Planning meeting.

  

Attendees:

3.     Team, Scrum Master, and Product Owner.

4.     The Product Owner is optional

 Retrospective Procedure

5.     All Team members answer two questions:

a.     What went well during the last Sprint?

b.     What could be improved in the next Sprint?

6.     Also team members can think on four Short Subjects:

a.     Start Doing

b.     Stop Doing

c.     Do More

d.     Do Less

7.     The Scrum Master writes down the Team’s answers in summary form.

8.     Scrum Master does not provide answers, but facilitate the Team’s search for better ways for the Scrum process to work for it.

Action Items – At The End

9.     The Team prioritizes in which order it wants to talk about the potential improvements.

10.   Actionable items that can be added to the next Sprint should be devised as high-priority non-functional Product Backlog.

More Details On Retrospective

11.   Type of Retrospectives

a.     Iteration Retrospective

b.     Release Retrospective

c.     Project Retrospective

d.     Surprise Retrospective

12.   Retrospectives Improvements: Retrospective offers multiple improvements.

a.     Improved Productivity

b.     Improved Capability

c.     Improved Quality

d.     Improved Capacity

13.   Steps to Conduct Retrospectives

a.     Set the Stage

In this step, aim at creating an atmosphere where people feel comfortable speaking about things that may not have gone well on the project.

Few techniques:

·         Check-In – Ask everyone to summarize in one-two words what they hope to get from retrospectives.

·         Focus On/Focus Off

·         ESVP - Explorers, Shoppers, Vacationers, Prisoners

·         Working Agreements

b.     Gather Data

Create a shared picture of what happened during the iteration.

Few techniques:

·         Timeline

·         Triple Nickels – Top Five Ideas, Elaborated By Five Groups, Five Times

·         Mad, Sad, Glad

·         Local Strength

·         Satisfaction Histograms

·         Team Radar

·         Like to Like

c.     Generate Insights

This step involves driving meaning insights from the gathered data in previous step and make sense out of it.

Activities done in this step help team interpret and understand implications of the issues before then move on to solving them.

Few techniques:

·         Brainstorming

·         Five Whys

·         Fishbone

·         Prioritize with Dots

·         Identify Themes

d.     Decide What To do

                        In this step, team will decide what they will change and how they will behave differently.

Few techniques:

·         Short Subjects –

1.     What Went Well,

2.     Do differently Next time

3.     Keep, Drop, Add

4.    Start Doing, Stop Doing, Do More, Do Less

·         SMART Goals

·         Retrospective Planning Games

·         Circle Of Questions

e.     Close Retrospective

                        Here team summarizes:

·         What the team decided to keep

·         What to change

·         What we are thankful for

·         Where we can use our time going forward

·         Express Appreciation to each other

Few techniques:

·         Plus/Delta

·         Helped, Hindered, Hypothesis

·         ROTI (Return on Time Invested)

·         Appreciations

Keep Blogging...

Regards,

Arun Manglick

Product Backlog Grooming

Backlog refinement (also called grooming),  advises teams to dedicate 10-15 % of every sprint to this activity.

Key Players:

• Product Owner
• Team
• Scrum Master

Process:

During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes:

• Adding new stories and epics,
• Removing user stories that no longer appear relevant
• Extracting stories from existing epics, and
• Creating new user stories in response to newly discovered needs
• Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
• Re-assessing the relative priority of stories
• Estimating effort for existing stories (T-shirt sizing) (Optional here, to be taken in Sprint Planning)

Benefits/Why is this helpful?

The intent of a "grooming" meeting is:

·         To ensure that the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority.

·         Groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours.

·         When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long.

·         By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.

How this is different than Sprint Planning Meeting:

At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint.

·         Time-boxed to two to four hours, this meeting is a conversation between the Product Owner and the team.

·         During the sprint planning meeting, the product owner describes the highest priority features to the team.

·         The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.

·         PO to answer questions, clarify acceptance criteria, or renegotiate.

·         Team sizes story in story points based on complexity and effort required.

·         Stories are broken down to tasks and tasks are estimated jointly in hours.

References:

http://scrummethodology.com/scrum-backlog-grooming/
http://guide.agilealliance.org/guide/backlog-grooming.html
http://www.capriconsulting.co.uk/difference-between-productbacklog-grooming-sprint-planning-and-elaboration/

Regards,

Arun Manglick

Three Amigos In Agile

Three Amigo is a process to get the various roles in a Scrum team together to have a common understanding about a Feature.

The aim is to create a common understanding and shared vocabulary across these individuals.

Key Players Involved:

• Business Analyst (Could Represent Product Owner/stakeholders)
• Developers
• QA Members

Essentially, this is a meeting during which the business analyst (BA) presents the requirements and tests for a new feature.

The Three Amigos (BA, developer, and QA) discuss the new feature and review the specification. Intent is to make these constituencies to be heavily collaborative (have conversations) around the Acceptance Tests or Acceptance Criteria for each user story.

Aim of the Three Amigos process is to bring:

• Shared understanding of the requirements across the Scrum team
• Shared understanding of the tests across the Scrum team
• Consensus about whether a feature was specified sufficiently and is ready to go into a development sprint.

Here is the process in detail:

·         The BA should begin the session by introducing the feature to the Amigos. Why is the feature needed? Is it like anything they've done before? Is there a visual design?

·         The BA should also present the requirements (prepared prior to the Three Amigos meeting). These will be reviewed by the Amigos, who will provide feedback, identify missing requirements/edge cases. The requirements should be updated in the session until the requirements are deemed ready for development.

·         The BA should then present the test scenarios (prepared before the meeting). These are also reviewed by the Amigos. Feedback is incorporated until there is agreement that the test scenarios cover the feature's expected behavior. This ensures good test coverage.

·         The developer is asked to identify Dev tasks that need to be done before development. For example, do they need access to an endpoint? Do they need to see variants of the visual design? These tasks are assigned and put on the current sprint board.

·         The QA is asked to identify QA tasks that need to be done before feature testing. For example, do they require access to a system? Do they need mock data? These tasks are assigned and put on the current sprint board.

·         Regarding estimating, the Amigos should have a common understanding of the requirements and tests. This is a good opportunity for the developer and QA to provide estimates.

·         The feature/specification should now be designated as ready for development. It has been accepted by the developer and QA and is ready to be assigned to a future development sprint.

Few Things To Note:

·         Timebox the Three Amigos meeting (30 minutes to 1 hour, max). Schedule it to occur one to two sprints before a feature is expected to go into development.

·         To embrace the iterative approach of Scrum, there may need to have several Three Amigo sessions in order to perfect a specification.

·         The developer and QA involved in the Three Amigos meeting should be the individuals who will develop and test the feature.

·         When specifying a feature in the Three Amigos, rather than using technical language (e.g., the JSON endpoint) or plain English (e.g., the financial instrument), prefer to use domain language.

Finally aim is – Accept only those features in development that have been Three Amigo'd, so that features are pulled rather than pushed into a sprint.

References: https://www.scrumalliance.org/community/articles/2013/2013-april/introducing-the-three-amigos

Regards,

Arun Manglick

Great Manager

I have always believed that managers are born, not made. There are certain innate qualities that a manager should possess. However, not every person who becomes a manager has all the great qualities that you would expect to see. So, in my opinion, these are the traits that transform a manager into a great manager:

 

·         Be Approachable – Whether you have a solution to your team member's problem or not, your team member should feel free to come up to you and discuss their issues.

·         Be Receptive – You need to be open to how your team members perceive you and your actions – you need to be open to negative feedback and also discuss about corrective actions, if any.

·         Be An Example – You cannot expect your team members to follow certain rules if you do not follow them yourselves – you have to set the example and lead the path – that is the true mark of a leader.

·         Be Assertive – When a team member is going down the wrong path, you need to immediately take corrective action and guide them back – if you are reactive and just point out mistakes without any guidance on how things could be handled differently, your team member will not know how to improve.

·         Be Well Judged – Not every team member needs to be monitored or managed the same way. Some people need focused mentoring, some people are independent contributors who require some guidance from time to time, some are go-getters and don't need much support – so don't use the same yardstick for all team members.

·         Be Appreciative – Whenever your team member does well, be prompt in appreciating – if we forget, they don't forget… J Shower your team with accolades when they deserve it! It costs you nothing!

·         Be Humble – Modesty as a manager is a very important quality to have. When your team sees you as another human being, who is just their bridge to upper management and who protects them in adverse situations, the usual barriers start to dissolve.

·         Be Objective – As a manager, you always have to play fair and be objective. You may personally like some of your team members more than others, but when it comes to a professional environment, nobody can be your favorite. Everyone has to be treated equally. That does not imply that you give the same professional responsibilities to everybody – that has to be decided based on your team member's capabilities.

·         Be Genuine – Most people can see through artificiality. As a manager, you have to care about the growth of your team members, and not as part of some goal-setting activity. You have to be able to understand their strengths and guide them to use their strengths to their advantage.

·         Be Fun – Nothing endears a team to their manager more than somebody who can let down his or her hair at times when the occasion calls for it. Sometimes the fear of losing the team's respect prevents you, as the manager, from participating wholeheartedly in team activities, and this can affect how the team perceives you.

 

I hope this article proves helpful to those who are struggling as a manager or are soon going to become one!

 

 

 

 

Thanks & Regards,

Arun Manglick, (PMP®, PMI-ACP®, PRINCE2® Practitioner, CSM®, MS-Project, CSSGB, ITIL V3, MCPD, MCTS, MTECH)

Project Manager - Forecasting
Mobile: 9158041782| 9850901262| Desk Phone: +912040265348 | http://www.synechron.com

SYNECHRON -
- 4,000+ professionals globally.
- USA | Canada | UK | The Netherlands | UAE | India | Singapore | Hong Kong | Japan

web - facebook - twitter - linkedin

❚ Watch: The Synechron Story ➪
❚ In the News: CNBC, Inc., Economic Times, ... ➪