I'll share my experience on how we shipped products faster using story maps and how team's focus on smaller goals than estimates / numbers / complexities helped us achieve it. 

The session would give an insight on:

  • Aligning team with product vision 
  • Shiping features fast / faster 
  • Better product backlog management 
  • Delivering without estimation 


Some of our challenges / questions were:

  • Are we delivering value ? 
  • How do we know we have delivered enough for our customers ? 
  • What is our priority right now ? 
  • Do we have a bigger picture ? 
  • Aligning team with product vision
  • Is tracking numbers the right thing to do ? 
  • How fast should we ship ? What are the related challenges ? 

We solved these questions / challenges first by using story maps and then removed estimation. Story map gave a clearer picture of what's planned and what's in the next customer release. Other ideas helped us easily identify when to ship and what to ship (I'll discuss more about these in the session). 

Story map is a great way to collaboratively identify the features, prioritize them and create milestones. We used story maps as our card wall also. It was an interesting experience :) 

No estimate helps the team focus more on goals and less on numbers. It helps the team to think more about the customers and how would they use the product and less about velocity, charts and commitment. It changes team's perspective and team starts shipping a usuable product for customers. 



Outline/Structure of the Experience Report

Presentation with examples (case study, learnings, challenges) : 35 minutes 

Question & Answer : 10 mins 


Learning Outcome

Product backlog using story maps 

How to focus more on functionality and less on commitment and numbers 

Ship product faster 

Align team with product vision 

Estimation is just another perspective 

Numbers doesn't matter 

Target Audience

Product Managers, Business Analysts, Product Owners, Developers, QAs

schedule Submitted 5 years ago

Public Feedback

    • Liked Linda Rising

      Linda Rising - Science or Stories?

      60 Mins

      Smart people are logical and objective. They (we) look at the evidence to help make the best possible decisions. We are not influenced by hype or emotion and as a result our behavior reflects the best the world has to offer. Cognitive science now tells us that these beliefs about ourselves and others (especially scientists) are wrong. All of us tend to make decisions based on intuition or emotion and then justify those decisions later with logic, a process called rationalization. The most influential element in our environment is not scientific evidence but stories. We love stories. Research shows that we are more likely to buy a product or embrace a process because of a friend, colleague, or relative and ignore evidence that might go against that decision. Are these bad things? Is there anything we can do about it? We have a long history of being influenced by stories and it has helped us survive. Linda suggests that the real answer is we need both approaches -- stories and emotion + evidence and logic. Both approaches have flaws and benefits. Linda will share examples and tell her own stories to try to convince you and try to help us do a better job of making decisions.

    • Liked Linda Rising

      Linda Rising - The Power of Retrospection

      180 Mins

      Project Retrospectives are an important part of any software development process. The Principles Behind the Agile Manifesto state that, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." How can this be done? By taking the time to reflect and learn and proactively determine what should be done differently in the next iteration, release, or project. Linda's presentation will introduce techniques for project retrospectives, whether they are agile or not. The techniques help teams discover what they’re doing well so that successful practices can continue and identify what should be done differently to improve performance. Retrospectives are not finger pointing or blaming sessions, but rather a highly effective process in which teams reflect on the past to become more productive in the future. Linda will share her experiences with leading retrospectives of several kinds for dozens of projects—successful and unsuccessful, small and large, in academia and industry. Her lessons learned can be applied to any project to enable teams and organizations to become learning organizations.

    • Liked Vinod Sankaranarayanan

      Vinod Sankaranarayanan - Ownership Transfer

      90 Mins

      Getting a different team to take over an application brings in challenges from multiple perspectives. There will be differences around processes, engineering as well as culture. Larger transfers would also involve changes to infrastructure. For long, the industry has done a disservice to this field by calling it Knowledge Transfer. Knowledge Transfer, is but a subset of the scope of activities involved in this exercise. We propose to rename this as Ownership Transfer.
      In specific - we put this process into practice with one of our customers. After more than 5 years of supporting the platform, ThoughtWorks worked with The customer teams to transfer knowledge and context back to the customer. A few highlights on the application.
      • More than 80% of all online ticket sales are done through this application
      • More than 400,000 visits a day
      • Close to 5 billion USD of ticket sales
      • More than 70 VMs supporting the production application
      • Upwards of 300 VMs supporting other development and testing environments
      A few highlights on the program,
      • More than 150 IT members involved in the program
      • A ramp-down was part of the process to get the final numbers to about 60
      • The transfer had to occur from Bangalore back to London
      • Infrastructure had to re-optimised from Bangalore over to London
      • Two organisations were involved viz. ThoughtWorks and the customer
      Since both Bangalore and London were following agile practices, the teams decided to utilise core agile concepts to effect the transfer. This became all the more important as business required critical features to be delivered on a continuous basis. 
      Before we started off on this exercise, we created a methodology to effect the transfer. This methodology is fairly context agnostic and should support a healthy, sustainable and mature way to transfer ownership. The transition itself was about a year long and involved multiple aspects around agile such as remote pairing, program MVP and above all, continuous delivery and non-disruption to business through the process.
      The session will introduce a framework that can be applied to most Ownership Transfer situations. In particular, this will be of interest to groups who are looking to transfer ownership from one team to another. These could be from a development team to a support team, or from one vendor to another as well. This will also provide insights on transferring ownership across distributed teams.  

    • Liked Sarabjit Singh Bakshi

      Sarabjit Singh Bakshi - Art of Processing People in batches - Lets Re-factor our Schools

      45 Mins

      My talk will be highlighted on the currrent Education System and how Agile and Lean Mechanisms can help us refcator our education System . As we all proceed in this digital world its important to understand what extra can we do to make our children education more informative and creative . Using Agile and Lean from Gurukuls to Modern school- what do we think -Is the current education system is helping our students . Would like to give an insight on where are we going how we can improve it and how we all can contribute to make it better. We can talk on using Agile as Change Agent towards transforming the way our children precieve learning. 

    • Liked Pankaj Kanchankar

      Pankaj Kanchankar - Line Managers - an Endangered Species in Agile

      Pankaj Kanchankar
      Pankaj Kanchankar
      Agile Coach
      schedule 5 years ago
      Sold Out!
      45 Mins

      The matrix organization of yore relied on maximizing returns on each skillset. This lead to having line managers and practice horizontals.
      Engineering managers looking after developers and practice managers looking after the respective practices of BA, QA and PMO. This lead to having multiple lines of reporting for team member whilst on the project.
      In Agile teams, focus is on the self organising teams of empowered employees working towards common success criteria (project success is team success). Not everyone can be a PO or a Scrum Master. So is the role of so called line managers or practice managers become redundant?
      Whats their role in the agile teams?
      How their role needs to transform

      In this talk I will be addressing these questions. Bring out how some of their responsibilities are now taken up by the team or Product Owner or Scrum Master. I will also be suggesting how line managers can take this as an opportunity to morph into more meaningful roles that help the organization and teams. 

    • Liked Jisha Sharma

      Jisha Sharma / Jyoti Prakash Datta - People Dynamics – Agility to our Rescue

      45 Mins
      Experience Report

      We (Jyoti and I) believe Agility is the mindset that makes you successful by doing what makes sense at any given point. Success in IT projects comes from not only following the mechanics but also applying your skills to people dynamics.

      We plan to talk about our experience where agility has helped us fight back in difficult situations than take a flight back. 

      Key topics

      People dynamics - 

      1. Flexing our styles
      2. UX at the center - Personas, Euro/Rs/Dollar test, MoSCow
      3. Workcell
      4. Big picture
      5. Customer shoes

      Agile Mechanics -

      1. Quantify priority
      2. Deliver in sprint 0 too
      3. Risk burndown

      Experience sharing

      1. Varied experiences 
    • Liked Shweta Sharma

      Shweta Sharma - Creating Business Relevance With Lean and Agile Practices

      Shweta Sharma
      Shweta Sharma
      Common Sense Worker
      schedule 5 years ago
      Sold Out!
      20 Mins

      Businesses are still struggling today to align their IT goals with their business ones. More often than not, IT projects are so focussed on budgets and timelines that they often miss the whole value proposition of the undertaking. 

      It is important therefore that along with keeping an eye on the timeline and cost, IT partners with the business and create a product roadmap which meets the business needs. For this to happen, the backlog needs to be in conotnuous evolution and business stakeholders need to be questioned on their prioirties and often rigid requirements sets.

      This is where agile and lean practices help: in getting working prototypes / products out at the earliest and failing fast if at they have to. 

      The talk will seek to walk through some real life examples from self experience, of how some IT projects failed succeeded by keeping business relevance at the forefront of their priorities, the practices these projects followed and the kind of client / business enagegment they demanded and obtained.

    • Liked Sridharan Vembu

      Sridharan Vembu - Turning around a twice-failed distributed enterprise program into success

      Sridharan Vembu
      Sridharan Vembu
      Head Engineering
      schedule 5 years ago
      Sold Out!
      45 Mins
      Experience Report

      The common myth about agile methodology is, it is suited for smaller, co-located teams, would not scale up for big enterprises and is best suited for smaller, less complex programs.

      In this talk, I intend to share how we went about setting up, executing and successfully delivering probably one of the most complex and strategic programs for one of our customers. This program was the first ever successful adoption of the fully distributed agile implementations for the customer.

      Context: The client is the leading Telecom Operator in the UK, having their captive and other strategic partners based out of India. The program was highly strategic for the client and the predicted ROI was high.

       - The implementation was tried twice by different vendors for more than an year, but failed to deliver; root causes were not analyzed

       - The Program Sponsor had one last chance to try and deliver the platform successfully, against a very tight schedule

       - Continued Operational risk with the legacy system in place 

      Outcome of our engagement:

       - Core functional application ready in pre-production by the end of first release cycle (4 months from engagement start); fully ready to functionally scale easily and quickly

       - Adoption of the technical and execution approach to other related programs within the portfolio 

      Our Approach:

       - Outcome of initial assessment of the existing codebase was to go with re-write from scratch; was a really hard sell, but was the RIGHT thing to do

       - Re-define the release cycle: extend development period by embedding integration testing as part of development cycle and cut down on the low level design phase

       - Need-basis colocation of functional SMEs with development team 

       - Direct access to Product Owners: weekly video calls, must-attend iteration show-cases, etc

       - Remove unnecessary operational overheads, in terms of people as well as organizational processes

       - Well-defined, pragmatic strategy for Integration testing (major constraints - lead time for test data preparation, limitation in re-usability of test data, lack of e2e functional understanding within team)

        - Smart seeding of other vendor team members (with good functional/domain understanding) into the core team

        - Zero compromise on basic hygienic practices: IPMs, Showcases, communicate negative-news-first with alternate solutions/workarounds, strict removal of wastes, inclusive decision making, highest degree of code coverage, sanity test suite, e2e basic automation suite   

        - Building trust between distributed teams: cross-pairing, align on core work hours across time zones, joint showcases and retrospectives (shared responsibility)

      Challenges faced:

        - Big push to release the core functional platform into production in 3 months (immediate next release)

        - Working out of other vendor premises: seen as threat to their business, lack of cooperation and collaboration   

        - Product Owners based out of UK, no easy / frequent access

        - Functional SMEs/designers based out of different location

        - Release cycle that was in place: 8 weeks of design, 4 weeks of development and 8 weeks of testing!

        - Distributed and isolated testing teams

        - Highly manual and time-consuming E2E testing processes

        - Multiple interfacing systems, both upstream and downstream 

        - Client development team based out of UK, different execution approach, lack of trust between the teams

      In summary, I would like to share the unique aspects of the execution approach that made this program a real success for the customer, though some of the approaches might be tried out in different environments and project situations.