Like / Dislike **We'd Appreciate Your Opinion**

Leave a Review! http://bit.ly/E6S-iTunes;

Intro: Welcome to the E6S-Methods podcast with Jacob and Aaron, your weekly dose of tips and tricks to achieve excellent performance in your business and career. Join us as we explore deeper into the practical worlds of Lean, Six Sigma, Project Management and Design Thinking. In this episode number 161, part 2 of our "Project Schedule Planning" series, this time the Agile,.. err SCRUM way. If you're just tuning in for the first time, find all our back episodes on our podcast table of contents at e6s-methods.com. If you like this episode, be sure to click the "like" link in the show notes. It's easy. Just tap our logo, click and you're done. Tap-click-done! Here we go. http://bit.ly/E6S-161 Leave a Review! http://bit.ly/E6S-iTunes

Estimation in Agile (SCRUM):

I What is Estimation used for?

a. For the team – So that can confirm what they are able to commit to

b. For the team – So that there is an idea/project plan on how much work is needed for the project to be completed

c. For the leaders/stakeholder – So that they know when what they are looking for will be done/available for use

II Estimation methods:

a. Absolute Estimation

i. Days

ii. Hours

b. Relative Estimation

i. T-Shirt Sizes

ii. Progressive Series

iii. Fibonacci Series

III Challenges with Traditional Estimation processes

a. Attempts to estimate things with highest level of precision when the least is known about the work

b. Make promises about dates without understanding the scope and capacity

c. Use valuable time asking for hour estimates that change many times; esp from wrong people

d. Does not account for skill level of the team; takes a generic approach to the to task to be done

e. Humans are terrible at absolute estimation

IV Question: So, if not time; what should I be estimating things on?

a. A: Estimations should be based on complexity and uncertainty associated with that task. A higher estimate means that the work that the team must do has a higher risk associated with it. Hence, the premise in Agile that try to make your stories as small so that the complexity and uncertainty associated with it is reduced as much as possible and the estimates are closer to accurate as a result.

V Who should be estimating the work?

a. It is always recommended that the people who are involved in the project should be the one’s estimating. Why? Because:

i. They have a better understanding of their capacity and what’s on their to-do lists

ii. They are able to discuss and get different view points on how the approach the task/project and determine the complexity/risk associated with it

VI How does Relative Estimations work?

a. Read out the task or story

b. Team asks questions to clarify acceptance criteria and story as needed

c. Discuss to ensure everyone fully understands the details of the task/story

d. Everyone individually estimates points at the same time using a “blind” vote method

i. Poker playing cards

ii. Planning poker.com website for remotely located teams

iii. Apps on phones that are developed https://agilescout.com/top-5-iphone-and-android-planning-poker-apps-agile/

iv. Post it notes with numbers/text printed on them

v. Using digits / fingers 

e. Discuss differences in estimates

i. Bring out the hidden assumptions

ii. Update acceptance criteria or story as necessary

f. Re-estimate again until:

i. Team reaches agreement

ii. Majority – pick the one that was chosen by majority

iii. In case of a debate still choose the higher one – To err on the side of caution

VII Advantages of Relative Estimation which is done by the team

a. Work is estimated by people who are doing the work, not the managers

b. Discussions help bring out the complexity of the story

c. Group discussions lead to better estimation

d. Everyone’s opinion is heard, builds ownership within the team

e. Easier to agree on relative size of stories

f. It’s quick and fun!!

Outro: Thanks for listening to episode 161 of the E6S-Methods podcast. Stay tuned for episode 162 where we continue our discussion on project schedule planning within the agile SCRUM framework and ruminate the challenges of attempting agile with a waterfall mindset. Don't forget to click "like" or "dislike" for this episode in the show notes. Tap-click-done! If you have a question, comment or advice, leave a note in the comments section or contact us directly. Feel free to email me "Aaron", aaron@e6s-methods.com, or on our website, we reply to all messages. We'd love to hear your thoughts on our LinkedIn Group. Why not join a discussion there? Just click the link to join. If you heard something you like, then Clammr and share it. Use Clammr to cut a 20 second snippet of audio and share the link with a friend. Don't forget you can find notes and graphics for all shows and more at www.E6S-Methods.com. "Journey Through Success. If you're not climbing up, you're falling down." Leave a Review! http://bit.ly/E6S-iTunes

Like / Dislike **We'd Appreciate Your Opinion**