Posts

Beware of stale story points

Like baked good that have been around for too long story points also go stale. The expiration date for story points is typically four to six sprints after the stories are pointed. Once the points go stale, they should be removed from the story, and the story needs to be re-refined and repointed. After time has passed, the team will often point a story differently because of what they have learned from other work they have done in the intervening time. The team may now want to take a different approach to the story, so re-refining the story is the place to start. In a similar vein, when your team starts working on a project that they recently inherited from another team, all points assigned to stories by the previous owners of the project are, by definition, stale. Each team is unique in its knowledge and abilities so each team needs to assign points based on the effort they feel the story will take to complete. Additionally, teams often point differently, so the points one team assigns
Post a Comment
Read more

Reaching for a well-crafted Sprint Goal

A recent sprint planning session with my team got me thinking about the importance of a Sprint Goal and how it is often glossed over. When well-crafted a Sprint Goal is very valuable to the team otherwise it is just a checking off the box for "do we have a Sprint Goal", which of course isn't very useful. Let's start by taking a look at what the Scrum Guide says about the Sprint Goal. the phrase Sprint Goal shows up 19 times in the current Scrum Guide. Under The heading of Sprint Planning - Why is this Sprint Valuable? , the Scrum Guide has this to say: The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning. The PO makes sure the team understands what value  they should focus on delivering in the current Sprint. The PO brings to
1 comment
Read more

Are you sure you want to spike that?

I have recently had some conversations about when it is appropriate to create a spike in Scrum. Is it when a team doesn't know how to approach a story? When they don't know how to utilize a tool or resource? When they have a question that they want to answer? Something else? I thought this would be a good time to dig into what a spike is, and what it isn't. The term spike comes from XP ( Kent Beck's Extreme Programming )  ( Spike | The Agile Dictionary ) .   A spike, paraphrasing  Ward Cunningham ,  should be a story that can convince the team that they are   (or aren’t)  on the right track.    One of the primary use cases of a spike is to help a team when they have a story that they are unable to estimate its size. Some stories are initially inestimable because there are questions that need to be resolved first. For example, the team may not know if a technology is appropriate; will it handle the expected load? In this case the team should create a spike. Inversely, if
Post a Comment
Read more

DevOps Teams by any other name

 “What’s in a name? That which we call a rose /  By Any Other Name would smell as sweet.” This line from Shakespeare's play Romeo and Juliet implies it doesn't matter what we call something. That its value and meaning are intrinsic in the thing itself.  Words have power, they shape our perceptions.  The pen is mightier than the sword . That phrase was penned in 1893 and is still very true today. How many times have you, or someone you know been taken in by an article on the internet just to find out later it was false? There was a recent survey to discover how many people fact check what they read on the internet . The result is that most of us don't fact check most of what we read and just assume it is true.  So, how does all this relate to DevOps? It matters what we call a collection of teams within an organization. What we call a collection of teams  is important. Are they Scrum Teams? Dev Teams? something else? The way that an organization refers to its teams affects ho
Post a Comment
Read more

Don't Ask for Forgiveness, Broadcast Intent!

"It’s easier to ask forgiveness than to get permission"  "It’s easier to apologize than to get permission"  We have all heard these phrases or something similar. I believe that there is a much better approach than asking for forgiveness after the fact, which is to Broadcast Intent beforehand. Be transparent with your intentions, tell people what you are planning to do. It is not asking for permission; however, it does leave an opening for conversation if others have questions or concerns. The phrases about forgiveness and permission are often attributed to Rear Admiral Grace Murray Hopper . She did help make their use more widespread, however the phrases didn't originate with her. Grace Hopper is one of the early pioneers in computer science. She coined the term debugging , although in her case it was the removal of an actual insect . Broadcasting our intent is something many of us do in our daily lives. Using turn signals when driving is a form of broadcastin
Post a Comment
Read more

The Sixth Scrum Ceremony

When you team is ready to mark a story as done what do you do? Someone just closes the story? Have a team discussion? Other...? The Scrum Guide discusses the Definition of Done , but it doesn't discuss how to make sure that a completed story has met the definition of done. An additional question worth discussing is when a story is done, how does your team ensure they have completely met the acceptance criteria? The criteria that was agreed upon with the stakeholder to know when the story is complete. My team  has found value in creating an additional Scrum ceremony to solve this problem. The scrum guide discusses the standard five Scrum ceremonies, which are required elements of Scrum. Hopefully you are not just going through the motions of those ceremonies but actually doing them well and deriving value from them. That is for a post some other day.  The ceremony I am talking about is Story Closing . We have found great value in closing each story as a team to make s
Post a Comment
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Post a Comment
Read more