Day: July 10, 2010

by Oren Ellenbogen on Agile, Management, Scrum

Confidence building: make it part of your Sprint

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 abuse 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.

p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.

 
by Oren Ellenbogen on Agile, Management, Scrum

User Stories do not replace Features

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…

 
by Oren Ellenbogen on Agile, Management, Scrum

Why Feature should detail full experience

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.

 
by Oren Ellenbogen on Uncategorized

How User Stories were born

“Agile/Lean movement” and Scrum in particular, made short cycles a key factor in the process. May it be cycles of planning, cycles of development or cycles of releases, there was a big arrow pointing at *short cycles* to figure out how to get more accurate, more responsive, more productive faster.

Due to the short cycles, the Features or “Product Backlog Item”, sometimes, just didn’t fit in. “My 2 months Feature won’t enter our 2 weeks Sprint!”. Because Sprint is, wrongfully in my opinion, being highly tied to releases, it raised a need to allow breaking Feature to multiple Sprints. The question is “how to break it right?”.

User Stories came to offer a methodology to assist in this need. The idea is to detail the Feature in multiple end-to-end flows (which good Feature already detail) and implement them one by one instead of trying to implement the entire Feature at once. Because User Stories are subset of a Feature, in the same language as a Feature, it felt that these stories can replace Features and Sprint will contain them as smaller execution parts. This will obviously “solve” the mismatch of Feature size to Sprint size.

I claim that it didn’t solve anything at the core level. Even worse, my feeling is that User Stories introduced a dangerous abstraction, one that should be used carefully. More on it in my next post…

 
by Oren Ellenbogen on Agile, Scrum

Feature, User Story and Task

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.