I was part of “Slicing Features into playable stories” session by Tarang Baxi in Agile 2012. Case studies Tarang presented were very effective in emphasizing the principles behind Slicing features into stories. Let me try to put down two case studies which he discussed.

First one was about an ipad app to allow users (travelers of an airline) to complete check in online via their ipad’s. This app is intended to support users in 12 countries. Also, most of biz logic is shared with website and other mobile apps which mostly is already in place.

General outline of the requirement was something like this

1. Initiate check in
   1. Ability to search  via last name,PNR
   2. Show a reminder letting user know that his flight is open for checkin (sort of check in notification)
   3. Login into account and use a dashboard page which displays booking  history (My Trips) and check in button next to it (both already in place)
2. Check in info
   1. Passport info etc for international travel
   2. Each country has its own UI layout e.g. Japan has last name then first name
   3. Country specify information if any
3. Extra / check in luggage
4. Add ons
   1. On board meal
   2. Wifi
   3. Upgrades
5. Payment for add on’s or luggage
6. Seat selection
7. Check in and send boarding pass based on user option/input Via email or To ipad

Now the question is what’s the best way to slice stories out of this feature (check in feature)? Product owner also mentioned that most revenue generating piece is obviously “Add ons”.

Principle: When slicing user stories, always ensure you get one thinnest slice end to end. In this case, first story team should focus on would be to get a base minimum flow to complete check in.  It could look something like.

I’ll talk about next case study in my next blog.

Agile is the buzz word these days. Everyone is talking about it. Interestingly many organizations / teams think they are agile. As Pekka Abrahamsson says, Agile is a non defined term, so it seems to be everything or nothing. There is no line to say if you cross that you are opposite of agile. Agile or Agility is a positive term everybody wants to be associated with . Being Agile is a journey, not a goal.

This series of blogs will try to touch up on few aspects of agile transformation. Recently, I was talking to a team which said they can’t be Agile (or follow SCRUM) because they are working on legacy code and they can’t have good unit test coverage or builds on every check in etc. The team was under an impression that if they following a couple of XP practices they would be agile . This kind of misconception is equally true at management levels who perceive Agile / SCRUM to be a silver bullet to solve all of their problems.

Why to Transform

Organizations need to have a clear vision why they want to “Get Real Agile!”.  In my opinion, there are 2 key goals why an organization / team should go for an agile transformation.

• Identify and effectively address challenges with their current base ground.
• Increase efficiency/ effectiveness by changing organizational / team working structures to increase predictably, adaptability and happy peopleJ.

Common challenges I hear with traditional processes

• Project timelines are missed.
• Product quality concerns.
• Project runs over budget.
• Unsatisfied customers. 

Agile Check:  Where do you stand now?

Agile transformation should be done iteratively. For this, we need a backlog of activities to deploy Agility / SCRUM into organizations.  This backlog is created (of course bound to change during deployment) during “Agile Check” with a cross section of the organization. Typically I conduct “Agile Check” with a group of 10 to 15 people which consists of managers, developers, QAs, team leads, architects etc.

Start Agile check with a stand upJ. Instead of a typical stand up, it’s about Name/Role, expectations from Agile check and anything they foresee going wrong during Agile check. This gives a fair idea of  mine as well as audience’s expectations.

Run a retrospective of their current process / structure. I like to give 6 post it notes to each individual, and ask them to write 3 positive points and challenges they currently face, one point on each sticky note.

Make groups of 3 to 4 people, don’t propose groups, instead, let me them arrive at it. Once they form groups, ask them to discuss among themselves and pick 3 positives and challenges at a group leave.

Each team presents their list then and a consolidated list of formed. Help them to arrive with top 5 positives and challenges from the consolidated list. I usually do it by voting. Each member gets 5 votes for positive and 5 for challenges. Each member can put his/her votes against the list based on what he/she feels important.

Now, we have a list of things that are working well and things to improve. Sometimes it requires some discussion around the same, but usually this is the time I give an introduction to SCRUM. Depending on the audience’s Agile exposure, this session’s focus ranges from explaining “Why Agile/Scrum” to core principles, and mapping them to retrospective list.

SCRUM Deployment backlog creation:

By now, groups would have understood what challenges they have, and how Agile/ SCRUM would help in addressing them. Ask teams to think about various activities which they feel are required to deploy SCRUM in their environment. Once every group has a list, help them to come up with a prioritized list. Usually I ask everyone what should be the first step. For e.g. someone would say, training is the first thing, someone might say, identify pilot project or management commitment. After this exercise, we end up having a prioritized backlog for SCRUM deployment.

That’s it, objective of Agile check is accomplished! A prioritized backlog for SCRUM deployment is ready.

Of course, once this is done, there is a management meeting when we identify and Agility Stakeholder, who owns this backlog and agree upon timelines, pilot project etc.

So this blog is about How and Why Agile Check. Stay tuned for more!