Scrum tales - part 3

Let's get back to the Scrum basics for a second - I'm seeing recurring issues regarding creation of Product backlogs and Sprint backlogs:

1) My team's Product backlog items are concise and can be easily understood by Product owner:

   a) "Review the handbook"
   b) "Implementing new CRM system"
   c) "Post 3 new articles each day"

Our team will excel during the next Sprint after Product owner sees this

No - you're pretty much toast after Product owner sees such undefined and immeasurable Product backlog items - all will be rejected. Don't worry, I got your back - here's how to fix this:

   a) Don't just 'review' but instead 'review and update' or 'review and send proposal'

   b) Don't work indefinitely, i.e. 'implementing' - instead just 'implement'

   c) Don't 'post N articles each day' - instead 'post X articles total' and define Sprint tasks how you will do this (per day, per week, divide among team members) - this is up to you to achieve the goal

2) We're planning a Sprint but some of the tasks are pure guestimates so we'll just leave them without any estimates in the Sprint backlog and move on

If you do that, how will you know that your Sprint goals are achievable for the time allocated for the Sprint? I know that Sprints are 'owned' by teams and ScrumMaster is only making sure Scrum rules are followed - however how can Sprint burndown chart be correct if you have no task estimates in the Sprint?

Instead you can do the following:

   a) Plan ahead for complex and large new Product backlog items - create new ones with higher priority that will allow you to first research and learn about the technology, what needs to be done and how long it will take

   b) Estimate with the help of the entire team - if you need 3hrs and your team member needs 6hrs, that means the task shouldn't be less than 4.5hrs

   c) If the estimates are wrong, update them later - that is why they are called 'estimates' and you update Remaining Work for each active task on a daily basis