Should you start with planning your sprints and then see how it fits your versions? Maybe start with versions and understand how your sprints look like? Maybe planning versions by themselves is enough? How do you start?

Decouple external planning from internal planning

External value (features your customers will enjoy) moves the organization. It is why you get paid. No one will pay for “let these kids develop for fun only”, this is why open source projects were born, for developers to write some code that may or may not be used by others. Versions are communicated out to your customers, named in a language your customers can understand “in version 1.0 we will allow our customers to upload their profile image” rather “we will integrate jQuery and develop highly scalable upload mechanism over Amazon Cloud”.

Internal value (features your organization will enjoy) keeps the organization fully operational, doing its best over time. It is usually not communicated out (your customers don’t really care if you’re using C# 4.0 or C# 3.0) and not named in customer’s lingo.

Versions are more tangible

Most of us stick to planning versions and our sprints actually look the same as our versions. We’re results oriented and we want to please our customers. Moreover, no external power is actively pushing us toward internal value.

Sometimes internal value > external value

If you’re strictly results oriented, you might produce great results but only for short, unpredictable periods. Sometimes you’ll need to delay customer’s value to handle broken “machine” in your factory. Your customers won’t like this delay, but they will understand it if you’ll offer tradeoffs and communicate “we are fixing internal machine to keep our high level of production steady”. They will prefer stable producing rather than insane, poor quality or unpredictable results.

Use Sprints to prioritize internal value with external value

Maybe you can devote 5% of the sprint to maintain your ability to produce fast? Maybe 10%? Maybe 1%? It’s really up to you to figure out what you want to push every sprint. Be careful of dismissing internal value, it’s your role to actively push for it.

How do I start?

I prefer to set some goals for my sprint first: (a) is there an internal value I want to push? (b) Are there people in my team that I want to push by leading features? (c) What is my team availability for this sprint?

With this in mind, I’m starting to plan my versions for the sprint and next one, making sure I understand perfectly what should enter the sprint and when. This is the first time I validate my plans. If the planned versions fully occupying my sprint (or even more than that), I raise a flag and trying to figure out if something can be shifted without causing damage. If not, and I have some “buffer”, it leaves me with understanding how much of my internal value I can push inside the sprint, alongside external value. This is the second time I validate my plans. Did I manage to push my goals to the sprint while producing external value? If I notice there is a big need for internal value that cannot wait, I will try to understand alternatives with our product team and supply tradeoffs.

Then, all is left is to organize when should each feature start/end and making sure external value (versions) are released on time while internal value is keep moving. Keep your head above the water, plan to last.

Sprint is a planning unit, keeping it stable during that time allows a pretended piece of mind for the developers from marketing/product ever-changing demands. So it feels anyway. We developers signed up a virtual contract with our product teams saying “we will be Agile enough to allow you to change your mind every 1-3 weeks, but don’t disturb us during that time! We want to work, not wasting our time on talks!”.

Does it make sense to you? Is this the true notion behind Agile? Would it be acceptable for a great business?

Well, it makes sense only if you think that waste is more valuable than your attention. Delaying smart decisions or cutting off bad ones after 2 weeks, 2 days or even 2 minutes is simply counterproductive. If you know that a feature selected for the sprint became a waste due to priority change, why should you move forward with it? why throwing the problem to the other side of the fence: “well, my product team should have been wiser with their priorities. We’ll do it anyway just to teach them a lesson so they won’t do it for next sprint!”

Priorities tend to change. It happens constantly. Don’t panic, be open-minded and make sure your team leaders can handle priority shift. It’s perfectly okay to say no, but make sure it’s a “reasonable no”. If you see it does make sense to move out some features and move in some others, do it with care, offer tradeoffs (“this change might mean we won’t be able to release the version on time, let’s delay it in 2 days”) and make sure motivation passes to your team. Your teammates need to realize that providing organized waste is plain dumb; they also need to trust you doing these changes with full attention, clarifying tradeoffs and setting expectations. Practice your agility!

After bashing prediction systems, claiming that measuring performance of your teammates to predict release dates or personal behavior is inherently wrong, you might deduce that I meant “measuring Actual Hours is pointless”.

On the contrary my friend, I believe that tracking Actual Hours is imperative for better planning and cutting off waste.

Translate internal units (Story Points / Ideal Days) to external units (Calendar)

How can you translate a 3 Story Points or a 3 Ideal Days to “it will be ready next Tuesday?”
Using Actual Hours, you could actually see a correlation between Story Points size (internal to the organization) to total amount of Actual Hours Range (external as you can put it on calendar). For example, you might notice after a few sprints that 3 Story Points (based on latest 5 features), are usually taking 23-28 Actual Hours to complete. Assuming you pick a number, say 6, as the amount of Actual Hours in 1 day a developer can do, such features will translate to around 4-5 working days. Story Points can be translated quickly, based on empirical knowledge, to a range of working days. This will make release dates predication much easier, assisting your Project Manager and your Marketing team to communicate it in their roadmap or create plans accordingly.

Actual Hours help to quickly balance effort in a Sprint

You’re on the first day of the Sprint and you’ve got seven Features (/ User Stories) in “Not Started”. You also made sure that people availability (Joe got 50 hours this sprint) is updated as some have vacations and some got exams during the sprint. Even more, you already decided who is the owner of each Feature. How can you balance the tasks effort, in hours, between your teammates? how can you decide if some features will be developed by multiple developers and still see that your plan is feasible? 
With Actual Hours history, from the example above, you can see that 3 Story Points translate to 23-28 hours. You can immediately add to all features worth 3 Story Points one task called TBD with 25 hours (~avg) and assign it to the owner. You move to each one of your features, checking their Story Points -> Actual Hours range, adding the task. Next, you slowly break this big TBD task, in each feature, into multiple TBD tasks, each with different owner and estimation, until you see that the effort is balanced between all of your teammates.

2 flows for example:

a. 3 Story Points (range: 23-28 hours) -> 1 task worth 25h for Joe -> 1 task worth 10 for Joe, 1 task worth 5 for Jim and 1 task worth 10 for Annie.

b. 2 Story Points (range: 10-18 hours) -> 1 task worth 14h for Jim -> 1 task worth 10 for Jim and 1 task worth 4 for Annie.

c. [ … until all work effort are balanced by availability and optimal ownership … ]
d. Make sure that your breakdown makes sense in terms of people availability. Make changes if needed.

Summary

Actual Hours are imperative as they (1) provide a way to translate internal work units to external work units and (2) allowing fast effort breakdown. The key is to set expectations right with your teammates, explaining why their performance measurements are so crucial and how they will be used. They need to understand so they will be able to honest, to have an incentive to help you. Don’t break their trust.

Many teams going into Scrum, have internal debates around whether or not moving to Story Points or sticking with Ideal Days. It seems that there is a lot of personal feelings involved.

Ideal Days – what is it all about?

Just imagine a work day without any meetings, phone calls or people bothering you. It’s a full day of making things done, full day working solely on your tasks, whatever that means.

Story Points – what is it all about?

Story Points are a bit more abstract notion. It includes 3 parts: Work Effort (how much effort the work will take), Complexity (implementing known yet complex code) and Risk (3^rd party integration, POC required etc). It inherently abstracts away the “who” to allow you to consider the “what”.

Estimation is expensive

I’ve said it before - estimation is expensive. You should find ways to make your estimation faster, unless you were specifically required to execute the Feature or bringing a super detailed estimation. If it’s not the case, and you were asked for numbers to determine Product Roadmap or feasibility of features, stick to fast gut feelings, may it be private hunch or collaborative hunch.

Fibonacci size – what is it all about?

To make estimation faster, it’s easier to have smaller list of options to pick from. For example, instead of picking a size from 1-100, you should pick from a smaller numbers range, like Fibonacci: 1,2,3,5,8,13 and then go to 20, 40, 70, 100. Why the jumps? Because the bigger the estimation, the bigger likelihood of being wrong or wasting too much time discussing how wrong. So instead of arguing on whether it’s 6 working days or 7, you just pick 8 or 5, depending on the specifics (effort, complexity, risk). The purpose is to estimate fast, not to be 100% precise.

Using Anchors

Usually, the idea is to price Features (or User Stories) against other Features *like* them. “This feature is around the same effort as that feature so it will be 3 Story Points as well”. After picking a few Features as “baseline”, it’s easier to estimate faster others features against them.

Ideal Days baggage

I personally believe that Ideal Days brings too much baggage into the discussion (making estimation slower):

1. Who’s Ideal Day? How long is one Ideal Day? Each member will consider her/his Ideal Day. Instead of focusing on fast estimation, everyone passing in their head “well, Joe is new in the team, it will take it twice as much! Let’s price it as twice as much then”. Story Points “don’t care” who is implementing the Feature. This is exactly how it should be done as you never really know who will actually be the implementor until you start working on it.

2. Ideal Days are not strongly correlated with estimating Complexity and Risks: People have in mind, when using Ideal Days, mostly effort involved. Story Points, due to its abstraction level, allows better focus on Complexity and Risk.

Matter of flavor, I guess

Anyway, I feel that it’s not really important whether you’re using Story Points on Ideal Days, as long as you (1) remember to price Complexity and Risk as well; as long as (2) you understand that estimation is expensive. I feel that Story Points offer better abstraction which allows faster estimation, but it’s really matter of “whatever works”.

Write down Estimation Reasoning!

Make sure you keep your estimation reason. “We said its 5 Story Points because it’s ~3 Story Points for effort and ~1-2 for Complexity and Risk. We felt good enough with 5 Story Points.” Why? If you would like to use this estimation as an anchor in the future, while trying to estimate a new feature, you should remember what the original 5 Story Points meant for you: “Was it 5 Story Points only because of effort?”

With a given time window and people, how much can you pull off?

Many managers are requested to offer a plan. Knowing how much you can actually deliver is one of the toughest question managers need to face with. It’s too elusive to measure it correctly, and there are many moving parts. You need to please your customers and your teammates, creating a plan to deliver external and internal value, picking wisely what is really feasible.

I tried to come up with a few tips to make this process a bit more structured, making it less elusive, less daunting and less “we’ll see as we go”:

1. Pick by External Priority – what will make your customers happy? Make sure you have the right priority from product / business teams and give it high consideration in your planning. At the end of the day, you are here to provide value to your customers.

2. Pick by Internal Priority – making sure you are building confidence as part of your Sprint. You want to excel over time, you must devote the time to allow it.

3. Pick by Features Size – try to see how many features of each size you can deliver in a Sprint. For example, after 2-3 Sprints, you might notice that you’re usually able to do X big features, Y medium features and Z small features. Usually there is a connection between feature size and QA effort or deployment effort, thus making this size estimation very useful.

4. Pick by Velocity – if you know you’re able to complete X Story Points (or Ideal Days) every sprint, based on your last 2-3 Sprints, use this information to pick Features to fit this number give or take. I always believe that you should aim for ~120%, to allow positive pressure which encourages self-improvement ideas, but don’t aim for failure or naïve success. There is nothing to gain there.

5. Pick by Personal Growth – you might pick some features to allow inner growth in your team. For example, you might notice a need to strengthen one of your teammate’s leadership skills by allowing her/him to lead bigger features. It doesn’t mean you should act naively; organization needs is more important than personal whims, but the organization will never actively push toward personal growth as a goal. It’s up to you to make time for it.

Many times when picking Features as execution unit, it’s hard to fit a big Feature into Sprint. This always cause the feeling of Features is too big as an execution units, leading some organization to prefer User Stories over Features, wrongfully neglecting Features over time. User Stories as execution unit are not the optimal way to go as they don’t provide enough value by themselves - you need to have “enough” Story Points to release a valuable version to your customers. They are also too abstract to understand the big picture, missing the overall why behind them. I believe that Feature broken into Tasks is a better approach and better execution unit. Obviously, there are multiple approaches to deal with big Features. You should pick the right tool according to requirements and people involved.

Breaking Big Feature, some options:

1. Extract design from execution: You can complete the design of a big Feature in Sprint 1 and implement it on Sprint 2. This way, instead of having a very big design effort and implementation effort on the same Sprint, you can use the first Sprint to understand effort and risks and use the second sprint to implement and deliver the goods, after understanding ROI better.

2. Extract framework from client: User Stories, just like Scrum in a way, introduce too many “Do’s and Don’ts”. For example, it’s considered a “bad practice” to have Technical User Stories. I believe that if the framework has specific needs (raised by the Feature) and it’s easy to break it out from the Feature itself (user behavior), it’s perfectly okay. It’s actually another step in the right way to build confidence as part of your Sprint!

3. Break big value to multiple smaller values (*caution*): Features, by nature, bring a value to your customers. It is possible though, to break the value into multiple Features, each carries only part of the value, without damaging the overall behavior. Instead of creating a “Search Engine” feature, it’s perfectly fine to define “People Search” and “Articles Search” as different features, each bringing different value. It’s even better to define sub Features inside “People Search” to enrich user experience over time, according to feedback by your customers. Caution: you need to do it carefully, sometimes breaking a Feature into multiple Features is silly as each doesn’t bring enough value by itself, until all of the pieces come together. Still, this is a powerful question to use: “Can we deliver real value to our customers by breaking this into multiple parts?”.

Most of the time, your Features should be small enough to fit a Sprint. It’s that simple - if the features are usually estimated in 2 weeks, don’t have a 1 week sprint. That being said, you should have the right (or at least some) tools to handle big Features. If it wasn’t obvious so far, don’t be afraid to “twist and mix Agile”. You owe it to yourself to understand why you’re doing things and adjust it if needed, even if it’s written in some book that it’s a “bad practice”. It might be bad for them, but it might be perfectly fine for you.

Once you decide how to break a feature into tasks, it’s crucial to make sure you don’t leave any leftovers as part of the breakdown. Feature breakdown must include each and every task to make it a complete unit you can deploy as part of a version. Completeness means that not only a Feature is deployable and it can be monitored, it’s also with great external quality (no major bugs left behind) and great internal quality (design-review, QA test-cases review, code-review, UI review).

You want to price a Feature by the gross organization time; this is the only way to understand how much a Feature really costs. Knowing that, you can correctly price future roadmap without needing “Bugs Elimination Sprint” or “Big Refactoring Sprint” to introduce quality after things were delivered to your customers.

No leftovers:

1. Design review – may it be over emails or formal meeting, the design should be solid and well thought

2. QA test-cases review – making sure QA will test the right things or add more test cases for relevant edge-cases.

3. Testing time - writing tests (unit + integration) should be priced as part of the Feature, not after, not next sprint.

4. Code review – for knowledge sharing and internal quality validation.

5. UI review – making sure the UI look & feel just like Product team wanted it to be.

6. Bug fixing + validation buffer – fixing major bugs should be priced as well! if you’re not sure how much time to spend, start with 5-10% of the total estimated effort, and learn from your experience (by Feature size, complexity etc)

You can add more to this list, if the team/organization needs it. The idea is to make sure that once a Feature is complete, you’re feeling great about it and got confidence it won’t be fired back to the kitchen, to cook from scratch. You should have the same confidence about changing an existing feature; it should be easy, voodoo-less and highly testable to do so, with low chances of breaking other flows in the system.

One of your responsibilities as a developer or team leader is to make sure you’ll be able to shine over time by constantly building confidence. This is why I strongly believe in maintaining a list of technical Features as part of your backlog. These are Features you believe will make the application more robust, provide better monitoring or make the team more productive (& happier) on their day-to-day work.

Have it to pass the message “we leave nothing as technical debt”

When someone in your team says “we really need to refactor this! it way too buggy and we cannot write tests for it”, don’t make it a technical debt that is written as a comment in the code or as a note on someone’s inbox. Make it a Feature, make it part of your backlog, pass the message that even though we cannot fix everything now, we will give it the right attention.

Have it to build confidence

Pick a few technical Features at each Sprint and make them a reality. This will make sure your team will be able to continue to produce fast and with great quality. Plan how much effort, from the entire Sprint, you would like to use to reduce waste - 1%? 5%? 10%? More? It’s really up to you. You need to balance it with thoughts of producing value to your customers while producing value to your team.

Have it for rough times

Having technical backlog is very useful when you need to re-plan the next few versions due to priority shift by the product teams, while your teammates are waiting for work. You can reduce pressure by letting them kill waste while you make certainty in the plans.

There are many ways to take a Feature and break it into workable unit of Tasks. Measuring “breakdown quality” is being ignored most of the time, as it’s very elusive to define “good breakdown”. The ability to break something into smaller pieces is one of the biggest signs of an experienced craftsman, so you should definitely challenge yourself by asking: am I known for predicting work effort well? detecting edge-cases early? Communicate progress to my boss clearly? being able to work with others on the same thing smoothly?

Introducing a Feature

Before we can play with breaking Feature into tasks, we need to have an example of a Feature in front of us. Let’s pretend that our desired Feature is “Signup and Sign-in” where to goal is to allow users to register and sign-in to the system. Next, here are the flows:
1. User can enter the signup page, if she’s not currently signed-in (else - redirect to homepage).
2. User can enter his details and signup.
3. User details will be validated, by [rules]. If failed - user will be asked to fix and re-send.
4. User will need to confirm her signup via email, before signing-in.
5. User can sign-in only after confirming her signup, if pending – show message.
6. User can sign-in in case she’s not signed-in already, using her credentials.
7. User can sign-out, only if she’s currently signed-in.
8. Page header needs to show relevant links, according to whether or not the user is currently signed-in.
9. If user fails to login multiple times (configurable), deny login for X minutes
…
[a few mockups here, a few technical/business notes there regarding URL structure, SEO to have in mind, analytics requirements, etc]

Breaking by Layers, the common way

A very common way is to break Feature by “application layers”:
1. Adjust database schema.
2. Create Data Access code to allow persistence of user (details, credentials encrypted etc) and retrieval of information.
3. Create Business Layer logic to validate credentials, confirm signup, perform sign-in.
4. Add signup and sign-in pages, alter header according to user state.
5. Add relevant validation on client side via javascript.

You can imagine that each task here will be a priced as 10-15 hours or even more, according to the implementer and the exact details. If the implementer founds an edge-case, it might mean that the every one of the layers here will be affected by it, making the estimation even less reliable.

Breaking by Verticals

A different approach will be using the flows above to form the tasks:
* create readConfiguration helper method
* create validateUserDetails method for server side
* create generateConfirmationNumber(userDetails) method
* create(/use) email sender provider
* create validateUserDetails for client-side
* create signup(userDetails) - schema to store user details, Data Access and Business to validate information and activate generateConfirmationNumber for sending confirmation email.
* create signup page (using validateUserDetails, signup method)
* create signin(credentials) method – schema to store number of login attempts, Data Access and Business to validate information, blocking user due to multiple attempts.
* create confirmUser method - Data Access and Bussiness to validate confirmation
* create signup confirmation page.
* create signin page
* create isLoggedIn method
* change header links according to status (via isLoggedIn)
* redirect user on entering signup page when currently signed-in (via isLoggedIn)

It’s not a 1:1 match between Task and flow, sometimes one flow will require multiple Tasks, but the flows drive the breakdown. No doubt, all of the tasks here are much smaller, each will take around 1-4 hours and very self-explanatory.

Why should you prefer Verticals breaking?

Confidence in achieving progress: if you strive for small tasks (up to 3-4 hours), it means that you’ll need to understand exactly what is needed to be done before committing to it. Every time you’ll finish a task, you’ll feel better that you’re moving on the right path. Because tasks are small, you will enjoy this feeling a few times during a day, which is important. You need to run away from “I wrote some code today, but I’m not sure if I’m on track”, poor planning will make you feel unproductive for long time.

Provide complete context to allow sharing workload: what happens if you need someone else to assist you? If you work by layers, it’s hard to understand “what is done”. The context is the entire Feature, which is too big to share easily. By working on vertical tasks, the context is much smaller as flows are smaller unit of execution. If you’re stuck, you can raise the flag and ask someone to assist you by taking a few vertical tasks and make them happen. They’ll have no trouble understanding what needs to be done.

One of the responsibilities of a great execution team is to make sure they will deliver in great speed and great quality, over time. “It’s a marathon, not a sprint” might be a confusing statement if you’re actually using Sprints in your development process ;)

What do I mean by “confidence building” and how does it affect you? Well, I believe that you need to earn others confidence over time, making sure your customers, internal and external, are happy with your results. For that you’ll need to make sure you understand what’s expected from you, to reach deadlines on time, to raise the Red Flag early and offer alternatives, to deliver product with great quality and to produce estimation that prove themselves as meaningful. Your job is to keep the execution machine at full speed and building the confidence as you go.

My recommendation is to make sure your Sprints will contain some internal maintainability time so you could stay on track rather than “have a good Sprint once in a while”. Here are a few thoughts:

1. Bugs elimination – making sure the backlog is not overwhelming. Pick wisely, based on ROI given by product and technical teams.
2. Provide rough estimation on the Features in the roadmap, review previous estimations and see if you were close.
3. Push small POC for risky features to come.
4. Create technical design for big/risky features you plan to address next sprint.
5. Eliminating technical waste – small refactoring to enhance team productivity.

You can either treat them as features, or simply buffer some availability of the team to handle this.

No matter what, do not burnout the trust people have in you; your boss hired you because s/he trusted you to do well, it doesn’t mean you don’t have to work hard and continue to earn her/his confidence in you. It is a marathon, after all.

User Stories became very trendy when Scrum became popular due to its smaller abstraction level; this made it possible to break big Feature and adjust its pieces into a single Sprint. I think this was taken too far, where User Stories sometimes completely replace Features. Not only I believe that Sprint should not be a release unit, I also believe that User Stories are not the correct work unit in a release or a Sprint:

1. Losing the why –User Stories by themselves are incomplete: they are missing the *why* - why do we think it is wise to develop this all experience? User Story describes only a small portion of a full experience. If we want to have real discussion on the value of a new capability, we must understand the full picture. The value always lies in the forest, not in the trees.

2. User Stories are usually not valuable to the customers by themselves - If you break a Feature into 20 User Stories, how many completed User Stories are enough to release the Feature? You cannot give your customer the Story of “A user can enter his password, the system will validate it by [rules]” without actually letting him register to the system. Your customer might enjoy tracking the Feature as you develop it this way, but you probably cannot release a version with 2 User Stories out of the 20 needed.

3. Maintaining another abstraction is expensive – what happens if a Feature changes? If you’re holding your User Stories separately, you’ll need to update them. Sometimes, as mistakes being made and it’s hard to sync papers, you’ll update one and not the other. So your business team, as an example, will work with the Feature paper but your QA team with the User Stories. Abstraction is smart only if it is beneficial over time.

I believe that User Stories are too pricey to be used as planning and execution units; they abstract a lot of the significant value Feature has to offer and introduce fragility in the process.

What User Stories are good for?

I would use User Stories only as a lingo between developers and business/marketing teams. They are small enough to be discussed without thorough background and big enough to explain behavior and expected outcome. I would not use User Stories to plan my sprints or my releases; I would aim to work in units I can deliver to my customers and discuss value of complete experiences.

How to adjust a big Feature into a Sprint?

More on it to follow…

Sometimes, multiple Features offer multiple experiences to the same motivation/goal/pain.

This is why it’s so crucial to document the why, the motivation, the pains, the reasoning behind a Feature. Although “The why” is crucial, it is not enough by itself. A great Feature must also detail the experience our users will enjoy, may it be capabilities, flows and look & feel. Only then, we can understand the purposed reality, before it is a reality - before we develop it and spend money to bring users to play with it.

With that, a real discussion on whether this Feature will be the best way to achieve this goal can take place. If you let your team be part of your vision building, by sharing the pains and goals, you can get invaluable internal feedback during “thinking time”. Fixing the Feature flows, improving usability or look & feel, before it’s developed, is always cheaper than doing it after it after the fact.

Many confuse the terms Feature, User Story and Task. I believe it’s important to grasp the difference between them as each one serves different purpose and sometimes even different audience.

Feature

Feature is a detailed experience of how your users will do something with your application. In order to make “something” meaningful, a Feature must include (1) the reasoning behind it, the motivation, “the goal”, “the pain to solve” – without it, it’s simply impossible to judge Feature’s ROI in terms of value versus effort and money. Once this is in place, Feature should include (2) user flows. A user flow might be “User can click on the delete button to delete his record, this will popup [a message] for him to verify first”. Usually, a Feature will be built from multiple flows, edge-cases and wording to make sure the grand experience is fully complete. To help relating flow with look & feel, a Feature should (3) include mockups and other accessories. Lastly, (4) business (and even technical) notes should be added to wrap up the experience: URL structure, SEO considerations, user messages user, analytics requirements etc.

Language: customer’s lingo.
Estimation Size: Ideal Days / Story Points / T-Shirt sizes
Clients: Internal and external: development/marketing/business/analytics teams and also your customers (to share with them on feedback forums, blogs).
To Include: (1) reasoning (2) flows (3) mockups and (4) business/technical notes.

User Story

User Story is a single “user flow” from a Feature I described above. “User can enter his password and re-enter it for password verification. If the passwords are not matched, the system will show a message”. Another example: “User can enter his password; the system will check the password’s strength by [rules] and notify the user if the password is not strong enough”. By itself, from User Story is hard to understand the entire picture, but it’s a smaller unit of work to plan and execute by.

Language: customer’s lingo.
Estimation Size: Ideal Days / Story Points
Clients: mostly internal, sometimes external - some User Stories just don’t make sense on their own, without the Feature as complete background.
To Include: (1) flow (2) mockup and (3) business/technical notes.

Task

A task is a specific “todo” with a given work estimation. A Feature can be broken into multiple tasks and so does a User Story. A task will be something like “Add new column to database called Rate and model it in the application – 1 hour of effort”, or “create javascript function to validate input on price field – 1.5 hours of effort” or “create landing page for our campaign with Nike and connect it to our analytics system – 3 hours”. Task resolution will always be much smaller and much more technical than Feature or User Story. It will explain what to do rather than why.

Language: development/marketing/business lingo.
Estimation Size: Hours
Clients: internal only!
To Include: technical information needed.

As I mentioned, you should not tie sprints and releases together. I thought to add a few notes about what will make a Sprint Demo really great. Luckily Moran Haviv, our legendary Project Manager at Delver, wrote a great recap I thought to share with you:

Why Sprint Demo?

· The primary purpose of the Demo is to communicate, share and celebrate what everyone managed to do in the last sprint and what is the value of it for the user/Organization; In other words: what are we doing here and Why are we doing it?.

· Collect valuable feedback to make sure our users will love our product as much as we do!

· Teams gets to show off with their output/artifact to everyone; (even if the software has no UI it might yet deserve to be presented by a good story).

A few guidelines for preparing great demo

• Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
• What is a good Story? Or How can you tell it :
  • Use a meaningful relevant theme;
  • Demonstrate sequence of events as the user would experience them (tell the story);
  • Use realistic data and characters—use examples and names from your user community or members of the development team;
  • Make it Exciting and Entertaining
• Keep it short. focus on what’s interesting and what’s valuable about your feature (you don’t need to exhaustively cover all your acceptance criteria).
• Prepare. Create any necessary test data.

Separation of Concerns

Working by the “scrum book”, sprint is also a release unit, in which you want to complete all the effort you committed to your clients and demonstrate it at the end of the sprint. Well, not in my book. Sprint should be remained an internal unit of time. Sprint is used for planning, for doing and for reflection, to make the team work better over time. It doesn’t mean that your customers will enjoy adjusting to your schedule.

I prefer to leave release cycles outside, as they are external unit of time. You need to adjust them to your customers, not the other way around.

Let’s say that you picked 3 weeks as a sprint size after considering “big enough, small enough” values. If you tie sprint and release together, that means that your clients will see things every 3 weeks. That might be fine, but it won’t allow you to challenge yourself to reduce release cycles. Even worst, the customers might demand a shorter release cycle to earn confidence in your delivery. A dangerous move, in my opinion, is to reduce the sprint size to match desired release cycle. This move might violate the “sprint should be big enough to avoid unacceptable overhead of planning/reflection” principle. Yes, your customers will be happy but your developers won’t. It won’t last. You want both internal team and external customers to be happy and enjoy a process that pushes them forward rather than pushes them around.

What is a Version?

Version is just a bunch of capabilities with a specific target date attached to it. Version is easy to communicate out: “we plan to allow a user to upload image, crop it and update his profile image in version 1.1, which is targeted to July 20th”. Basically, for each targeted date you specify a list of features, enhancements, reports etc. The customers gets to say when the versions should be aimed for, according to their needs.

What does it mean about Sprint Demo then?

Well, if the release cycles are shorter than sprint cycles then the Sprint Demo will become a show off by the team to each other rather to your customers. Obviously, you may want to add another “Release Demo” meeting for your customers (and maybe include the team in it). By doing Sprint Demo internally, the teams will get the chance to see what’s going on “on the other side of the corridor”. Oh, did I mention that this is also fun? It allows the organization to collect valuable internal feedback to make sure our users will love our product as much people who wrote it!

“Sprint” – what does it mean?

Note: my definition of sprint is not by the book. It’s perfectly fine by me as I love adjusting theory to practice; I hope it is okay with you as well. Basically, a sprint is just a time window that you plan to achieve something at. Just imagine a box with your interesting “todo” notes. For example, in the next 2 weeks you may want to plan to perform some proof of concept for your initiative; plan to create 3 landing pages to check which one covert users better to registered users; plan to write a tutorial or even plan to upgrade your team’s computers.

Why do I need to define a specific time window then?

The idea of a sprint, in essence, is simply to (1) ease psychological acceptance of changes and (2) allow shorter, just-in-time planning.

Specific time window, made constant (sprint after sprint), allows you to understand that things might change and you now made mental and physical “room” to adjust when needed. It’s a bit of sugarcoating, of course, but it’s making the transition smoother.

The just-in-time planning part is more “acceptable” when you’re embracing the fact that it’s too damn expensive trying to break all effort into small pieces. You’re customers are “allowed” to change their mind, so – what’s the point of understanding that something being requested for next year, will take 121 hours to develop? In 2 weeks, hell, in 2 days, this effort might cancelled. Breaking future effort to small pieces is great, but only if it’s extremely cheap to achieve or extremely relevant now. Until then, you might be okay with high level estimation.

The perfect size: big enough, small enough

Sprint should be big enough to (1) achieve meaningful progress and (2) avoid unacceptable overhead of planning + reflection. That means that if your smallest effort is always at least 1.5 weeks, don’t use 1 week sprint. If you need a full day to plan a sprint and another to reflect on how it went, don’t use 1 week sprint. Otherwise, your people might feel “we’re doing nothing but planning and reflecting”.

Sprint should also be small enough to allow to reflect and adjust often. Just like “release often” attitude, adjust often will make the organization work better, faster. Don’t dismiss it lightly.

How many sprints should I plan in details?

Good question if I may compliment myself for asking so. I would aim for detailed plan at least 1-1.5 months in advanced, unless you’re in a really volatile market and 1 month is “too far”. If your sprint size is 2 weeks, then I would say around 2-3 sprints. By saying “in details” I mean very detailed understanding of effort, real breakdown or very solid understanding, based on similar effort in the past or one-of-a-kind magic ball. The idea is to have good image of near future; this will obviously be expensive to create, but will give you confidence on how to achieve the most important goals on your table.

I would try to understand what’s coming later on (3-6 months), but invest much less time and stay with high level estimation. I don’t want to waste time on planning potentially irrelevant effort.

Natural dependencies planning

When sprint size picked wisely, there is much “smoother” feeling of dependencies planning. There is no real need for Gantt or something of that sort, thank God. Everyone will be aware of the effort being made in the sprint and will align dependencies accordingly. The feeling will be more natural, more just-in-time rather the stating “we need infrastructure team to finish in 6 months something so we could use it 9 months from now!”. It doesn’t mean that dependencies planning is gone out the window, you’ll still need to do so for big infrastructure effort, but you’ll see that it happens less than you were used to. This is a good thing.

Reflect and adjust

At the end of the sprint, it’s a great time to sit down and consider what went well, what wasn’t (take Action Items) and what can be done to have better sprint next time. You’ll adjust to external changes better when you’ll adjust to internal pains better.

I thought that Agile == no planning

Now, that is just sick. Seriously, no one is expecting you to work badly. Great planning is the only way to produce great products to your customers, deliver it on time and with high quality.

Not all planning are born equal

Accept it, plan accordingly :)

Moti and I have decided to form an invite-only Scrum Clan.
We would like to tag Pasha Bitz (snapshot below) as the 3rd clan member.

Pasha, choose carefully, you can only tag one Scrum-Lover like yourself to this distinguish clan ;)

p.s - If you want to be part of the Scrum Clan, please drop a comment and you *might* get an invitation...

                                                    

                                 Scrum Rules !

After almost 1.5 months of Scrum at Semingo (a baby startup), I decided to expose the way we work at the moment and talk about the adjustments we've made in order to suit Scrum to our needs.

I'll start with our implementation to the Daily Stand-up Meeting. No doubt, our meetings are pretty funny (most of the time) and create the right vibe for the Team. The one thing I love most about our meetings is that by the end of the meeting, I know what is the general work-plan for each member in my Team.

Now it's easy to know what I'm planning to complete today (I spend 5-10 minutes planning my day before the meeting), when & if I need to finish something earlier (or at least decide about interfaces after the meeting) in order to integrate with others, help out or ask for someone's else help(code review for example), stay after the meeting in order to talk about something that pop up during the meeting, remove impediments (if I can) and most importantly - have a good laugh before the day begins.

Daily Stand-up Meeting (aka DSM) structure at Semingo:

When: 
Every day at 10:30.
Where:
Meetings room.
Time Box:
15 minutes.
Attendants: 
Pigs only (Chickens can (only) listen)
On the table: 
Each Pig answer these 4(!) questions:
(1) What have I done since the last DSM ?
(2) What am I planning to do until the next DSM ?
(3) Impediments - what bothers me to work ?
(4) Am I on track?
     If someone feels that one of his tasks won't be finished as planned, a flag is raised so the Team could assist. 
     The same goes if someone feels that he's going to finish before the expected time. 
     This means that he could help out someone else or take a few extra tasks we did not plan for the current iteration.

Notes:
Only one Pig talks at a time and he leads the conversation if reasonable questions comes up. He (alone) has the power to stop a conversation if he feels the conversation stray from the DSM path. Team members can decide to talk about an issue that was raised during the DSM just after the meeting is finished.

What next (DSM planned improvements)?
(1) You late, you get (punished, that is): each team member that late to the DSM must wear the "I was late to DSM, I will serve you coffee today" sign on his shirt.
(2) Red-Back on track: If the conversation is getting out of control (too many jokes, drill-down conversations, more than 1 Pig talk etc) - the red button is clicked and each Team member is being electrified with 120V. Well no, but it could have been a nice feature right? Clicking the red button will make a nice GONG!! so we could move on. The Team agree to listen to the GONG and get back on track, so we could finish in time and keeping the DSM productive.