Authority is a red herring here. Do and iron.
-Not a true indicator because people estimate @ the end of the week
-We need to use the 5 Whys to find out what is driving the request
-We could start with other metrics first. Maybe just counts could give enough information to steer by
-Morale goes down when tracking per story
-There is no customer value in tracking hours
-Maybe we can learn the same things in different ways that don’t affect our team so negatively
-Takes a lot of time
-Maybe we should worry about time tracking when we start recharging, but not before then.
-What is the problem we are trying to solve? Let’s just fix it. Don’t force people to track time if you already know that the problem is that we are doing too much maintenance or something similar.
-If we are going to time track, we should do a small timeboxed experiment to see if the data helps to steer change.
-It should be Showable! If you were going to do a show and tell, what would you show? That’s the stuff that should be in the Acceptance Criteria.
-REMEMBER: A story is an artifact for a discussion. Every story should have a discussion with the team and customer.
-A good format to use is Given When Then. Andy recommends that we not have more than 3 sets of Given When Then in each story.
Erik told a story of how a friend's company radiated information using Google Real-Time Analytics of their website. Through this, they found that their landing page took over 6 seconds to load. Once the team learned that the page was taking so long, they implemented some caching that took it down to just over 2 seconds. The business was able to bring in an addition $1M each month because of this small change. He mentioned the story was only a "2 pointer". High value? Heck yes.