Scrum won’t fix any of your problems!

Ahhh, it’s out! Scrum won’t fix your problems. Ok, in some chaotic situations it will bring order into the game (like the speaker in the british House of Commons :)). But everything else it will only show you very transparent. You will have to find the best ways to solve your customer problems and yours. You are in charge to fix your broken culture, the conflicts in and between your teams.

Scrum only gives a frame. You remember how the Scrum Guide starts with “Scrum is a framework for…“. And that’s it. A framework giving you the chance to work with consistency and even more important: transparency. If you do it right, you will end up with an endless stream of problems to solve. Scrum shows them unforgiving. You will have to talk frequently about them. And it divides the problems into “how you work”, “what you achieved (or not)” and “what your next goals are”.

Conclusion

A huge pro of Scrum is the big transparency it brings to your organisation. It helps to develop every part of your process in a human centric manner. And on top it is easy to explain!

Hard thing is, that culture is hard to change. There can be resistance. Unaware values can make things even harder. Often you see high expectations and when people realize not everything will end up in well in a wink, they are disappointed.

What are your experiences with Scrum and the expectations at it? What disappointments did you saw? Which resistance did you realized and how did you got over it? Leave a comment and let the world know!

As always thanks for reading and sharing! I hope you liked it!

Scrum is just another leadership attempt

Lets put a finger on some hard spots: Scrum is no silver bullet! It will not fit in every situation. On top it will not be the best solution for every situation. Whenever the humans in the organisation aren’t ready to accept and internalize the mindsets behind Scrum, it will not work.

Next spot i want to look at is what i call the holy knowledge how it should be. The Scrum Guide leaves much room for the implementations. This is on purpose. There is room for finding the best fitting solutions for every problem you and the organisation encounter. You can’t expect that two randomly implementations of Scrum are exact the same. Ok, you can, but you will be disappointed! No two organisations have the same

  • customers and their needs,
  • employees and their knowledge and needs,
  • roles and rules and
  • relationships and contracts.

Having said this, we must step back and admit, that there can not be a role, event or artefact that has to be exactly as you imagine it or saw somewhere else. Everything may differ. And it is ok! I dare to say everything should differ to fulfill the specific needs.

So lets accept, that Scrum is just an attempt how to solve problems. It is a great one, with many pros. But it is not more than one of many leadership attempts.

What is Scrum for you? Have you stumbled upon somebody stubborn? Let the world know and leave a comment!

Thanks for reading and sharing, hope you enjoyed it!

Effective and efficient Daily Scrums

Lets talk about one of the most important meetings in the Scrum framework: the Daily Scrum. It is, as the name says, hold on every day of the Sprint (ok, just on the working days :D). In the daily the team comes together to find out how the Sprint is going, what could be a risk to not reach the Sprint Goal and how to prevent not finishing the most important stuff. With important stuff here is ment the things which give the most business value.

The famous three questions

The most frequent thing you hear or read about the Daily Scrum (e.g. the Scrum Guide) are the following three questions every team member should answer:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Lets have a short look who you need in a Daily Scrum. At least you need the team members (not the whole Scrum Team). Often it is good to have the Scrum Master and the Product Owner there too. The Scrum Master can give hints how to handle certain issues or point out risks which the team is not seeing. Also she can help the team focus more on improtant and necessary stuff. So for instance he can point out, that the team is premature optimizing a not yet proven solution or not focusing on customer needs any longer. The Product Owner can be a listening and answering part of the Daily Scrum.

Three questions – the dark side

The risk with the “three questions Daily Scrum” is, that the team is just doing a report. If your company has the structure, that the Product Owner is also the boss of the team, chances are high, that the team is not selforganizing and swarming around the problems, but just looking direct into the eyes of the Product Owner/boss and reporting to him. They will tell him what they have done and what will be done next. But even if there is no such structural antipattern the risk of unseen risks is given in this approach of the Daily Scrum. This risk comes with the three questions, which are easily mistransformed to the following questions:

  • What did I do yesterday?
  • What will I do today?
  • Do I see any impediment?

Maybe you see what happened? We completely lost the focus on the important part, the Sprint Goal. The questions are sounding very similar. If you don’t look, or better listen, carefully, it seems alright, that the team answers the shorter questions. But: without the focus it is very probable, that the team forgets fast which reason they have: the “Why?”, the “What for?”. The team lost the focus on the customer needs. Now the team can fill the fifteen minutes of Daily Scrum with unimportant chat. They can seem very busy and look like hard working, but can achieve no business value at all.

Other reasons for hidden risks can be fear or shame. If somebody isn’t feeling safe, she can come into the state of fear, that is the obvious way and shouldn’t need further discussion. The other way it is possible to become fearfull, if you have a hidden or personal goal. For instance you want a raise or a promotion. Than some colleagues tend to bury their mistakes deep under a mile of talking about nuts and bolts all the time. If somebody is ashamed, because she can’t solve a problem, the same can happen. Important here is transparency and security. Work into the why and fix it as deeply as possible!

Why Daily Scrums?

Short break and remember whatfor we do have Daily Scrums: we want to assure, that we reach the Srpint Goals. Therefore we plan on a very small scale what to do next. And we want to identify handle risks as early as possible. With this early access to the risks, we can plan the Sprint as safe as possible. Back to the How!

How to organize an efficient and effective Daily Scrum

The approach i am writing about is based on Eric Brechners presentation. He is talking about Kanban, but that’s no problem. I tried it with some teams and had great results. The teams were focused on the most important things nearly all the time. It is really simple: everybody answers just the questionAre there any risks or problems for reaching our goals?

  • Are there any risks or problems for reaching our goals?

The focus is just on the things which can go wrong or are already going wrong. First we decide, if it is an important issue. If it is not solvable on the spot, we don’t talk through the solution at all. We focus on the second question:

  • Who will solve this issue with whom?

You can decide to go person by person, story by story or just throwing the question into the room. Just figure out, what works best for the team. In my teams we only asked into the room and gave everyone a look. Normally every issue came out on their own, only sometimes a question about a topic was needed to see the risk.

Later we realized that focusing only on problems, issues and risks is a bit demotivating and we added “Are there joys or are you proud on something?”. That made the Daily Scrum much more fun!

Conclusion

Have you tried this method for Daily Scrums? Or the three questions mentioned in the beginning? Or a completely different method? Let us know and write a comment!

As always i hoped you liked it, thanks for reading and sharing!

Divide and rule in Scrum – the events

Sometimes it is fun to have a look on old knowledge from a different point of view! In this case the old knowledge is Scrum-you’re familiar with it, right? The viewpoint i chose today is the good old divide et impera or defeat in detail! As already announced in the first blog post about the roles in Scrum, here is the next part of the mini-series: the Scrum events in the light of divide et impera. Enough chitchat, let’s dive in!

The events

The official Scrum Guide talks about five Scrum events: the Sprint, the Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. We will talk about them one after another!

The Sprint

I see you asking “How is the Sprint splitting anything?”. I asked myself too and here it is: by taking always small chunks of functionality, or even better business value, putting them into one Sprint and completing them one by one. Seems too simple, right? And it truly is very basic. When the Product Owner does a good job, the developed items are ordered by the maximum value. Here the divide et impera gives us the power to develop every section of the application only up to the point when another one has bigger value. This is one part of the huge power of Scrum – the biggest customer value wins! So we are dividing the “what” into doable parts while staying able to react very fast and not waste time on finishing unused features!

The Sprint Planning

The first meeting and the starting point of every Sprint is the Sprint Planning. It is there to shape the Sprint Goal and how to achieve it. The Scrum Team makes the very first step on the “how” level. Often this is done in two steps: looking for possible ways to achieve and than deciding which way to choose and clear the way further.

Another way this meeting divides and rules is by splitting and sorting: if a Product Backlog Item is too big for one Sprint, it is divided into several smaller ones until something fits in. If a Product Backlog Item is to expensive at all, it gets out of the Product Backlog. Hopefully!

The Daily Scrum

In this very effective meeting the Development Team goes through “how” questions of the most important Sprint Backlog Item. The team focuses on how to reach the given Sprint Goal as best and fast as possible. This can mean to decide who does what till the next day. Who will check which possible prototype idea or who will implement what part (maybe in pair programming with who). We have a further division of the how in a more detailed granularity.

The Sprint Review

In the Sprint Review the whole Scrum team looks at “what have we done?”. It is the counterpart for the Sprint Planning-here we look backwards on what was finished. If the Product Backlog Item was only a part of something, here is the first chance to decide, if we adjust this part, go further on the way or spend time and energy in another feature set.

The Sprint Retrospective

The place to look at the “how we are working” is the Sprint Retrospective. Here is the division: in the Sprint Review we looked at the “what was done”. By this segregation of concerns it is assured, that we have a focus on reaching the goals and improving always over time. So we work to reach our business goals and assure to be or become more agile/flexible/professional/whatever our market needs. This Janus-faced character is a wondrous feature of Scrum.

Conclusion

So we’ve seen, that the Scrum meetings are full of dividing and ruling on different stages and at different times. On an abstract point of view there is no need for breaking things more down than it is done in Scrum. If its done right ;)!

What are your thoughts on the Scrum events in general and in this point of view? Do you have something else you want to read about? Would you like to look from another perspective or do you want to see an other part of Scrum analyzed? Did you liked this blog post? Let the world know it and leave a comment!

Thanks for reading and sharing ūüôā i hope you liked it!

Divide and Rule in Scrum – the roles

When thinking about Scrum what is coming in your mind first? The Scrum Master? The Sprints? The Product Backlog? Whatever it is, lets have a look on it from another angle: the good old divide et impera or defeat in detail! There are many historical persons who are attributed with it. We will not cover this part here, it could be a longer story :)!

With this blog post i am trying something new – at least a bit new for me: a series of shorter posts on a bigger topic. Let me know, if you like this more or the old way of sooo looong articles!

The roles

One part which i love about Scrum is the separation of concerns (sorry, deep in my heart i am still a software developer) of the roles. On one side we got the Product Owner. She, and only she, is responsible for the “what” is done and the “why” is it done. Business value and its maximization is her key responsibility.

Then there is the Team. Their business is the “how”. Nobody, not even the Scrum Master, can tell the Team how a specific thing has to be done. The Scrum Master has the right to intervene and ask, if there isn’t a better way to do things. But the Team has the final say!

Last but not least we got the Scrum Master. Her sphere of influence is the Scrum framework, its understanding and the living of it in the whole organization in the best way possible. With best possible here is ment, that the Team rises to high velocity and stays there. While we have many smaller parts in the servant leadership of this beautiful role, but in my eyes they fall completely under the correct understanding and living of Scrum and the high velocity of the Team.

Conclusion

Overall for me the Scrum Team is the best example of divide and rule! I love, that for every important part of the business there is somebody personal accountable. That gives Scrum the power it has! In the next blog posts you will read about the events, the artifacts and maybe the rules in Scrum corresponding to divide and rule.

What are your thoughts on Scrum in this point of view? Do you have something else you want to read about? Another perspective or another part of Scrum? Did you liked this blog post? Let me and the world know it and leave a comment!

Thanks for reading and sharing ūüôā

Daily Scrum Antipatterns

Let’s have a look on a very central thing in Scrum in my eyes: the Daily Scrum. You can find a section in the Scrum Guide and many other places in the web. Living in the heart of every Sprint and every day of the Sprint, the Daily Scrum is the meeting for the Development Team to plan the next day. As you may read in the Scrum Guide, the Scrum Master and others are allowed, but they are not allowed to disturb the Daily Scrum. The Development Team decides how it wants to do the actual meeting. The Scrum Master only has to assure, that the meeting takes place, that the team is able to hold the 15 minutes timebox and that no outsider is disturbing. One common myth is, that everybody has to answer the holy three questions. That’s simply not true. The three questions are a good start for new teams to find a way to talk every day about the Sprint Goal. And that is the point where i want to start sharing my experiences and little stories.

Actual Antipatterns

The first thing i want to share is the “forced three questions”. Here the team lead forced the team members to answer the three questions. Without a doubt, the team had no right to improve or change the situation and was not empowered to organize its work as it wanted.

Another one i saw multiple times is the “i’ve done this and that”. The team members didn’t focused on the Sprint Goal. If you have a close look at the Scrum Guide, the three questions, there is always a “meet the Sprint Goal” at the end of them. So team members chatted about phone calls and refactoring a class and fixing this bug. But the Sprint Goal was not focused. And that’s a problem! The team should focus on the Sprint Goal and find a plan to reach it in the Daily Scrum. It is a inspect and adapt meeting, if the first plan got impediments in the way, the team has to adapt and change the plan.

Very close to that is the “hiding what you’re doing beside the Sprint Goal”. There one or multiple team members did things, which had nothing to do with the Sprint Goal and did not tell anybody. This is a violation of the Scrum Values focus, openness and maybe also respect. When someone of the team is not working together with the rest to reach the goals, it is unfocused and maybe also harming the morale of the remaining team and company.

Another thing what can be hidden are the mistakes. So the anti-pattern of the “hiding my mistakes” is harmful cause nobody will learn from them and they will be done again and again. This is a waste and should not be permitted. Whatever brings a team member to hide a mistake should be taken really seriously. If there is a broken culture, than the Scrum Master must have a look at it. It should be fixed as soon as possible to not end up in a situation where nobody is showing his errors and nobody can learn from them. Without being courageous we can’t adapt to the reality!

Talking about the culture i have to admit one pattern i saw multiple times is the “report meeting”. Here everybody is giving his or her report to the boss or the felt next higher tangible person. So if the boss is somehow once not there, than the Scrum Master is the recipient of the habitual report. There are two misconceptions. First is, that you have to tell what you’ve done and present your personal plan to someone. Second is, that the Scrum Master is higher than the team member. The latter shows a misunderstood Scrum interpretation. The Scrum Team is completely equal. The power is partitioned to have someone responsible for every important part in the development of complex products: the team is responsible for the how, the Product Owner for the what and the Scrum Master for the process. They are equal and together they build something great.

Quite similiar is the “chatty boss”. The boss is talking nearly all the time and even exceeding the timebox. He is giving everyone a task and looking for presenting himself. As you read through all the other patterns, there is nothing to add why this is a sign of not working Scrum.

The “forced metric” i saw and heard multiple times. For instance the team lead forced to fill the happiness metric. Without a doubt, if the team wants to fill a metric, that is clearly allowed. And on top it is a good sign for having some healthy habits. It shows, that the team may focus on side goals or true norths like better bug rates or better code quality. Being forced to fill a metric is a sign for a not so good understanding of theself-organising thingy.

Another hard thing i remember in one team was “the silence” or “the elephant in the room”. There were nearly no discussions or a hard atmosphere. Everybody was happy when the meeting was over. At least it felt like a big burden was gone after the Daily Scrum finally was done. That could’ve had several reasons. A new boss nobody liked or a cold conflict n the team were nobody wanted to get in struggle or some other hidden things. Here it is important to find the root cause and to fix it. Sometimes the Scrum Master can do this, sometimes he has to delegate it to HR.

Conclusion

Many misunderstandings of Scrum and the concepts in it can lead to Daily Scrums, which are not so valuable as they could be. Sometimes the Daily Scrum is a good indicator, that something deeper is broken. That could be the culture or the relationships. Than it is important to make this things transparent and to adapt to the reality.

What anti-patterns did you saw in your Daily Scrums? And how did you handled them? Which things helped and went something to the complete wrong direction? Just leave a comment and let me and the world know about your experiences!

Thanks for reading and have a good Daily Scrum :)!

Story Points

After i’ve wrote about User Stories there were some questions about the closely related topic of the Story Points. I will try to cover those in this blog post.

What they are

A Story Point is an artificial estimation measurement for a User Story. It is artificial on purpose. We don’t want to have it exact, because this would take us too much time to reach. The main value in estimating in Story Points is this: the ideal Story Point estimation makes every story, which is estimated with the same scale by the same persons comparable to every other story for which the same things apply. We need this two conditions, the same scale and at least nearly the same group, for important reasons. If we try to compare stories which are estimated with different scales, we are comparing the famous apples with oranges. This will not help in seing how long a team will need to finish the given set of stories. Same applies if completely different people estimate the stories. Even if they know the original scale, they will see the world through different eyes. Which makes the estimation different. This can be good, if the estimation gets more realistic, or bad, if it is tending more to the unrealistic direction.

The difference of Story Points to the famous man-day is, that we not only have a look on the effort it will take, but also on the risk and the complexity. So a nearly effortless story with a huge risk can be estimated higher than a easy, boring, time eater routine story. Same for a not much to do, but complex set of tasks: it can be estimated higher.

What they are not

We are trying to make the estimation in Story Points more adequate but not exact. Trying to reach exact estimations would mean to have a complete plan for every step. With User Stories we try to give the team the possibility to explore the solution and work strong together. With the need of having exact times and an exact plan, we kill creativity, team work and the feeling of responsibility. As already mentioned Story Points contain not only the time! This is important to have always in mind, there is never a precise mapping of Story Points to a time needed or even to a precise point of time in the calendar. The agile part in Story Points is, that we try to get things like team work and responsibility in exchange for the illusion of an exact plan. Things will always go wrong and no plan survives the project, so we let the planning phase be a bit short and gain other values out of it.

How to get a first baseline

My first teams to be introduced into Scrum and Story Point estimations had a situation, where not everybody was comfortable to estimate. The reasons were somewhere inbetween estimation by management and hard deadlines made by sales without asking. Here comes what helped everybody not worrying, but just going: we layed out a Fibonacci sequence of cards (1, 2, 3, 5, 8, 13, 20, 40, 100) on the middle of the desk. As you may note, from twenty on the Fibonacci sequence is broken. That’s for easiness, everybody can remember twenty, fourty and one hundred. But try to remember 21, 34 and 55. Yep, only a little bit harder, but think in two weeks again. Back to the main topic! We take the first story, discuss what has to be done. If it fits around the eight or thirteen, we put it on the desk in between those two numbers or on one of them. If it is somewhere else, take another story to start, till you have one which fits between eight and thirteen. Ask everybody, if there are open points to discuss with this decision. If so, talk and move the card till everybody is happy with its place. Now take the next story. Decide, if it is bigger or smaller than the first. Try to find a good place for it. Take always only one story and sort it into the already given stories. After every story reflect, if the card sits correct where it is and if you need to rescale all the stories for a better measurement. Reasons for rescaling can be that everything is on one side of the scale in a range of two or three points or if there are stories which seem to fit nowhere. When the team found enough stories fitting in the scale, let them choose for each point of the Fibonacci sequence an example story. These stories you bring with you whenever the team will have to estimate the next two or three times. They can be seen as reference points, if there are differences in the points of view. After a while everybody should have a common feeling what an amount of Story Points meens.

My experience with these steps:

As mentioned the first teams i guided through the learning how to estimate had distrust against estimations. For this situation it was way easier to just talk about one story at a time than have the discussion why to estimate and how to do it. The guys were open to follow it step by step and no big discussions came up. The guided tour through the process made it easy and painless for all of us. When we came to the end it was even the case, that the team members came up with suggestions how to rescale and were in vivid discussions about if a story is a five or an eight. My theory is, that whenever you go through easy steps with a group of people, they tend to come with you. But if you tell them “we’re going to xyz” they can come up with the complains and boycotts. To me seems to be like in the great book Facilitator’s Guide to Participatory Decision-Making. There is a theory of how to get people painless to get to a solution or decision by guiding everybody through phases. There you first open the solution space and than talk through the possible solutions to find the best solution (or the least worse one ;)) and choose one solution in the end. Really excited made me, that even new guys had an easy time to get into the estimation after a few months. Almost everyone new to the team made it after just one time with only watching to get really fitting results! One developer made it arlready in the first Backlog Refinement she participated, to come up with fitting estimations. That left me speechless! The last observations i want to share are the following: there developed a game thingy in our estimations which is like “if everyone has the same number, than we get a shot”. Nope we aren’t drinking at work. Even if it seems as a good idea :)! That made the Backlog Refinements and the Sprint Plannings real fun, thanks for that guys! But its important to mention, that everybody knows, that the differences in the later on blind estimations are more a big value. Because we afterwards talk why the values differ. Within that talks we discover risks and clear questions.

What are your experiences with estimations in general and especially with Story Points? Have you ever asked yourself “How to get these guys to estimate?”? What worked well for you and what absolutely not worked?

Leave me a comment and tell me what you liked or not liked about this article! Thanks for reading and have a great estimation :)!

User Stories

Everybody who came in touch with Scrum or Agile heard about them, many used them and still there is confusion of what it is and how the Best Practices look like: you’re right, i am talking about User Stories! For the easier writing of this blog post i am talking only about Scrum here. But it fits to other Agile methologies too. Lets dive into the topic!

From theoretical point of view, a User Story is a requirement. User Stories are a subset of requirements. User Stories have a common look and feel, also called a common structure. There are mutiple kinds of structure for User Stories in the english wikipedia article described. Here i will take this classical style:

As … (role/persona) i can … (what) so that … (value/benefit).

For more clarity lets have a look at some easy examples:

  1. As Administrator i can manage users in the backend so that i do not have to insert SQL queries into the database.
  2. As User i can find web pages easily according to key words so that i do not have to rely on web pages which i or my coworkers already know.

As you see, this examples are a bit open. They leave space for the how to reach the goal exactly in many ways: there is no exact description how the user interface has to look, there is nothing said about how to reach the goal technically and finally it is not said how the user is guided to reaching his goal. As a good product owner you leave this level of granularity in your user stories until the team decides to be a bit more detailed to reach several goals:

  1. first of all you want to compare business value of your features, so you want to assure, that no technical or other solution detail distracts you while talking to stakeholders about “What’s more valuable for you, feature A or feature B?”
  2. than there is the part, that the team should be involved as the solution experts they are in the refinement and solution definition.

The first point helps you to keep a vivid Product Backlog. Also it helps the whole Scrum Team to focus (one of the Agile Values) on things which are important. Also it helps you and your Scrum Team to only do the preparation work necessary for the next upcoming Sprints. You don’t want to have a huge set of fully refined User Stories. As you may already have realized, the world sometimes changes. And so the markets do too. Some markets change really fast. The User Story you’ve written today can be invalid in a year or even a month. Or it could be, that it has to be changed on a non-trivial base. So it costs you and your company time, energy and money to maintain a big, fully refined Product Backlog. Somebody will be in a situation where she is remembering that one ticket/User Story which is nearly what is now under debate. But it is hard to find! Once in a while somebody needs to clean up and walk through all the User Stories and decide if they are valid any longer. With valid here is ment if they are not done yet or they are not longer the need of the customer. So my advise to you: there are better things to do with your time than maintaining millions of future maybe items! You’re here (in your company ;)) for only one thing: create value for your customers!

The second point helps the individuals in the team to feel connected to the solution they build. If they are involved early and can freely design the how, they have not only influence on what is going on, they really shape their work. With this said they can feel more self-efficient. And who is not feeling better, if she can build her own surrounding and decide how its done. For the why it doesn’t¬†matter if team members are free to find the best fitting User Experience or the technical solution, both things should lay in the teams decision circle.

Properties of good User Stories

Another good hint into the direction of great User Stories is the “INVEST in Good Stories and SMART tasks“. The things proposed there are a good true north and ment more as a best practice. Often you find different definitions of the letters of the acronyms, so i decided to give you both words in case i heard of them. Lets have a short look what the acronyms meen.

Good User Stories should be:

  • Independent – the perfect set of Stories has no dependency, so we can implement tham in the order we decide. Unluckily it is not always possible…
  • Negotiable/Negotiated – the User Story of our dreams is not finally fixed and not very detailed. We are allowed to leave solution details open.
  • Valuable – that one is easy and hard together: we need value for at least one customer. Without customer value, we should not think about writing down a single letter or loose time and money.
  • Estimable – we need Stories, for which we are able to write down a number. Hopefully it is a Story Point ;)! Seriously: if we can’t say at least “This Story is as big/complex/risky as that Story.” or “This Story is bigger/more complex/riskier than that Story”, we are not able to compare the User Stories. That hinders us from being able to decide how a good Plan for the next Sprints looks like.
  • Small – a story is best, if it is not too big. The size described here is ment in two meanings: the story should be doable in few weeks by one person and it should fit on one card. The few weeks restriction helps us to keep the estimations for the User Stories realistic. The bigger the story, the wider the range of not hitting the real corridor with the estimation. To restrain the written size of the story helps us to not use a whole concept instead of a User Story. It forces us to break down bigger stories and Epics (very big User Stories, our example number one could be one) into fitting ones.
  • Testable – we need realistic stories. One way to achieve this is to think about how the story could be tested. If you have no idea, how you could test the story, than the chances are high, that your User Story is somehow not clear. Sometimes it is likely, that you have non-functional requirements. For example you want your application to be high performant or as small as possible. This things can be added as acceptance criterias like this: “the application should be live usable” or “the application should fit in 5 megabyte”.

Good Tasks should be :

  • Specific – hmm, that one is easy and hard at the same time: the tasks in a User Story should not be “design” or “implement”. That should be done latest in the Sprint Planning. They should be something like “implement the method save of the user controller”. So you see, we need very granular information what should be done here. Important side note: the team should decide what tasks to do, not the Product Owner or the Scrum Master. The later one can and should point out better ways and should not let the team get away with the given weaknesses. But he never should force the team to one specific solution.
  • Measurable – the example from the last point is very good measurable: either the method is implemented or not. “Fix the bugs” is a bit harder to measure. This comes from its unspecific formulation. Which bugs are ment? All known? All existing? Only a subset like “the new introduced”? Here the measurable is often tied to the “specific” property.
  • Achievable/Attractive – here we have two properties in the smart acronym, which point to slightly different directions. On one side a task should be doable in one Sprint and overall, that’s what we call achievable. On the other hand it should be meaningful for the customer, the team or the company. So there should be a sense behind everything we do.
  • Relevant/Realistic – this is another two-sided part of the smart acronym. As the attractive of the last letter, the relavant is pointing to the sense. We don’t want to have useless work done. This would be also called a waste of time and money. So we focus on relevant things. The realistic is somehow pointing to the achievable. With a task like “make the rendering of the finished, postprocessed animation movie happen in under a second” will not be reachable without huge preprocessing or huge computing power.
  • Time-boxed – There should always be the wish to finish the task in a given time. In Scrum this is easy: we want the User Stories done in this Sprint. Therefor all their subtasks and all other tasks should be finished in the Sprint too. Hopefully your Sprints are time-boxed too :)!

Now we have seen how the User Stories and tasks should look like. Lets take a short step into why, when and how to split things. As often the aim is to reach a reasonable granularity. We want our stories as small as necessary. This helps us to get to the point where we can estimate them very accurate. On the other side we don’t want to break them into too small pieces. So we want them as big as possible, to not have to deal with five thousand User Stories per Sprint, which is in the most environments a huge administration overhead.

How to refine User Stories

How can we go from the first version of our User Story to an adequate, good-sized final version? About that topic you can find plenty (quick) guides and advices spread all over the web. I like the Quick Reference Guide for Splitting User Stories from the agilelearninglabs for its conciseness and its powerful tools. It is a good starting point for a best practise for your team. It consists of these steps:

  1. Split, when you see conjunctions (and, or,…).
  2. Replace generic words with specific ones.
  3. Write down acceptance criteria, they:
    • are pass/fail conditions, that prove story is done or not
    • can become smaller stories
  4. Do a timeline analysis:
    • pretend the story is done
    • What sequence of events happen while the usage?
    • each event can be an own, smaller story

Lets go through this steps with the example User Story #1. You don’t have to scroll up all the way again, here we have it again:

As Administrator i can manage users in the backend so that i do not have to insert SQL queries into the database.

First question of a team member could be “What is ment with manage Users?”. As you see, in the first iteration we skipped the step one, cause there is no conjunction, and proceeded with step two. The Product Owner can answer now “create, edit and delete Users”. So we end up with the

As Administrator i can create, edit and delete users in the backend so that i do not have to insert SQL queries into the database.

Now we have the conjunction “and” and are able to split the Story into three smaller ones:

  • As¬†Administrator i can create users in the backend so that i do not have to insert SQL queries¬†into the database.
  • As¬†Administrator i can edit users in the backend so that i do not have to insert SQL queries¬†into the database.
  • As¬†Administrator i can delete users in the backend so that i do not have to insert SQL queries¬†into the database.

For brevity we only look at the third story from here on. It has no conjunctions and deleting is not very generic. Now we can proceed with the third step. An acceptance criteria could be as following: “the user is permanently unavailable from the whole system”. The team members can now ask, if they should remove the user completely from the database (step four starts: timeline analysis). Than the Product Owner can ask his lawyer and answer that the user data have to be stored for the timespan X and afterwards should be deleted completely. With that information the story can for example be refined to¬†

As Administrator i can delete users in the backend so that i do not have to insert SQL queries into the database.

Acceptance criteria:

  • the data of the user isn’t removed when the user is deleted
  • the data of the user is kept for at least for the timespan X after deletion
  • after the timespan X after the deletion of a user the data are automatically and completely

For now this one looks well defined and razor sharp.

Another example splitting

Lets have a look at the second example User Story. Here it is again

As User i can find web pages easily according to key words so that i do not have to rely on web pages which i or my coworkers already know.

The first refinement step, looking for conjunctions is not getting us further. There is only one between “i or my coworkers”. So we go directly to the generic word “find“. Here we can split the Story into the search and the results display like this (for brevity we leave the benefit in an abbreviated form):

As User i can¬†insert my key words easily for a web search¬†so that i do not have to …

As User i can¬†view the result web pages easily¬†according to my key words¬†so that i do not have to …

A short note: if we oversee the generic word find, we could and would come to the same result in the timeline analysis in the fourth step. Back to the next step: the acceptance criteria. Lets clarify them only for the third story:

As User i can¬†view the result web pages easily¬†according to my key words¬†so that i do not have to …

Acceptance criteria:

  • the searched key words are written prominently on the result page
  • the result web pages are listed with a link and a short description

Lets go with the timeline analysis. While thinking of the users timeline, for me two things pop up. Firstly i am not sure if all the billions of maybe results should show up and secondly i am not sure, if the result page should be immediately shown or if there can be a link send by email when things are ready. Asking our virtual Product Owner brings us to this additional two acceptance criteria:

  • the web page is loaded in realtime (< half a second)
  • the result web pages are paginated results per page

Lets have a look at the complete User Story:

As User i can¬†view the result web pages easily¬†according to my key words¬†so that i do not have to …

Acceptance criteria:

  • the web page is loaded in realtime (< half a second)
  • the result web pages are paginated results per page
  • the searched key words are written prominently on the result page
  • the result web pages are listed with a link and a short description

The acceptance criteria can become new User Stories. Here the first sounds really like a huge thing (not forgetting to scan the whole web ;)) and should be extracted to standalone User Story.

Lets have a look on the INVEST properties with the result User Story:

  • Independent: the “maybe extracted” realtime story is not independent of the view results web pages story, which is not independent of the insert key words story… we have sometimes to deal with that.
  • Negotiable: all the result User Stories in this example seem for me to be¬†
  • Valuable: overall for every result User Story there is the value given by the why of the first one. Sure it can be written more clearly, but for demonstration it is enough to have it a bit raw here.
  • Estimable: the two result User Stories (inserting the key words and viewing the results) can be estimated. They are not vague. The realtime story carries a huge risk: we don’t know what we have to do to reach this. That one is nearly unestimable.
  • Small: like in the estimable point the two result User Stories fit the small condition too. Also the realtime User Story is here not really tangibly.¬†
  • Testable: for our result User Stories we can write real easy acceptance/front end tests. Also for the realtime User Story those tests are written easily and fast.

As you already realized, this User Stories describe the Google internet search page. The stunning part is, that we have enough space for the how part. The main benefit of this is, that the Team now has the freedom to ask questions about the wished solution, can be creative in the how and feel really connected to what they build. With this benefit we reach a situation, where they can go deep into being proud: they helped the organization to build something which gives value to the world. And i guess i don’t have to tell you that people with a why and allowed to build it how they want, tend to stay longer intrinsic motivated. So it is a real profit for the customers, the organization and the team.

Conclusion

We looked at what a User Story is, how good ones look like and how to refine them in an easy process. But this is only the tip of the iceberg. There are plenty other descriptions all over the web. For instance Richard Lawrence wrote a stunning article about Patterns for Splitting User Stories. I personally have good experience with the techniques i presented here to you. I love how concise and easy they are. For me they are best practices and i found them useful to start with and afterwards reflect what is fitting better to the team and the surrounding.