Email has for many become the curse of today’s paperless office. They pile up faster than you can process them. The fact that many emails are impossible to understand, or completely pointless, doesn’t help.
This post lists five principles that will help you write more effective emails that benefit both you and the reader.
Paired with effective filtering and inbox management you stand a much better chance of persevering on the email battlefield.
In Scrum, you develop product increments in short iterations called sprints. The sprint is a very central concept in Scrum: everything revolves around it.
In this post I talk about sprint length, preconditions for a successful sprint, and what to do when a sprint falters.
Each sprint starts with a planning event which I covered in an earlier post. The sprint ends with two other meetings: the sprint review and the sprint retrospective. Those will be covered later. These three events are part of the sprint, and make out the sprint boundaries.
Last time I wrote about sprint planning which is one of four formal events prescribed by Scrum.
In this post I explain what product backlog grooming is, when it is performed, and how it is done.
Backlog grooming is often performed throughout the sprint. Perhaps this is one reason why it’s not considered a formal event.
However, many teams do backlog grooming as an explicit meeting, and some people think it should be incorporated as a formal meeting in the guide, too.
email,
gmail,
gtd,
productivity,
tips
As I begun my new job, I moved to Gmail from Outlook. I also upped my daily email barrage.
Zero Inbox suddenly became very relevant again.
Setting up Gmail, I hade these three goals in mind:
And this is the prize we’re after:
Every sprint begins with a planning activity. This is when the Scrum team decides on the work to be done in the iteration ahead.
Sprint planning is divided into two parts.
During the first part user stories are analyzed, evaluated and estimated. After that, the developers determine a reasonable workload that they think they can commit to.
During the second part, selected stories are analyzed in more detail by the developers (remember, I use the term developer for everyone building the product, including coders, designers, testers, documenters, and so on).
“Time is what we want most, but what we use worst.” –William Penn.
Never is it more true than when it comes to estimating.
Indeed, to most people estimating effort is tightly coupled to time. How long will it take? When will it be ready?
This is futile: time is a moving target and calendar time, in particular, next to impossible to predict.
A better approach is to estimate the size, or complexity, of work, and to derive duration based on velocity.
In two previous posts, I have described what I think is necessary to become productive: getting organized and stopping procrastination.
It’s time to wrap it up with a summary. I will also offer a bonus tip that, while it may not be necessary, certainly helps gather the strength and energy to stay productive.
