Often, I get to hear questions about level of details that need to go in the product backlog stories.  How detailed should be the acceptance criteria? or how small the story should be? We all know stories matures with time. I really like this post on user story life-cycle. Please take time to read this. Let’s consider an example now.

User story evolution

User Story example: As a Project Owner(PO), I should be able to transfer complete project ownership to my connection, with my role remaining to be just a project creator(author) after transfer.

Note: At the first sight, it is tough to say whether this is a story or an epic. When this story comes up in backlog grooming meeting, teams might completely miss the magnitude of such stories.  Hence, as the product becomes bigger it is wise to start detailing stories by adding acceptance criteria earlier in grooming meetings itself. Impact of every new story gets wider as product becomes bigger which often gets missed by the team.

Hurry and Read the rest of this post!

{ 3 comments }

Recently I got interviewed by DiscussAgile on a topic known by several names, i.e. Specification by Example, Behavior Driven Development or Acceptance Test Driven Development.

Here’s the Google Hangout recording available on YouTube.

Following topics got discussed as part of interview:

  1. Why to do ATTD?
  2. How to do it?
  3. What skills are needed to do it?
  4. Who should do it?
  5. How it relates with Test Driven Development?
  6. Tools to BDD/ATDD.
  7. How to start?

Enjoy and provide your feedback.

{ 0 comments }

This year I delivered a presentation on “Distributed Agile Patterns” in Agile India conference held in Bangalore based on different patterns evolved or discovered during my Agile journey.

The video is available now. You may want to have a look and provide your feedback.

{ 0 comments }

Every Agile team has to deal with different emergencies next to their regular work. Every team dream of achieving sustainable pace comes with nightmares of production emergencies/defects, support and maintenance tasks within a sprint which takes focus completely off the sprint goals. The goal of this webinar is to see different approaches team can take to absorb a reasonable amount of uncertainty, striking balance between robustness and speed within the sprint.

Also we will discuss about how to deal with “Pivot” in lean product development. In this state, product has to go through a course correction in terms of vision, market segment and features. This is almost an emergency on business side. In webinar, we will see how engineering teams need to do course correction in their approach too.

Audience will learn:

  • How to plan for production emergencies during a sprint
  • How to apply strategic and tactical thinking to handle changes
  • How engineering team needs to deal with development when product is in Pivot

If this sounds interesting to you, please register for the webinar here. Do share with others too!

Webinar Timings: Wed, May 13, 2015 9:30 PM – 10:30 PM IST

 

{ 0 comments }

One of the basic but important customer expectations is – the software product should be of very good quality. That makes sense as well. However, what exactly “good quality” means?

free-vector-continuous-inspection_071694_continuous-inspection

Here are characteristics of good quality software:

Hurry and Read the rest of this post!

{ 0 comments }

We know “Testing As An Activity” is important, and why we should all test. The old axiom that “Testers Test and Programmers Code” is so outdated now and everyone needs to change. Testers are the testing experts in a team, and can help enable the whole team to own quality but they are certainly not the only one’s who should be testing. Like, developers need to contribute towards testing by unit testing their code and also pair testing to minimize defects and minimize test – defect-fix cycle.

Agil-Testing-Quadrants

Testing in agile, addresses the processes that produce software and also products of those processes. Hence I ask my teams to not just focus on validating software after development, but also check processes that produce software like, quality of stories, requirement/impact analysis, acceptance criteria(using behavior-driven-development to address “3 amigos problem), and more.

Take a look at our agile testing workshop which is a detailed 2 day course which focusses on test automation strategies, lean approach to defect prevention, various tools and techniques to automate, BDD(behavior-driven-development) and how to use various frameworks – Linear Scripting, Test Library Architecture, Data-Driven Testing, Keyword/Table-Driven and Hybrid automation frameworks.

{ 0 comments }

In our last post, we discussed about how to break performance measures into team and individual measures to bring more team behavior orientations into appraisals. 

Today, let’s talk about addressing other two issues: feedback frequency and how to make feedback effective.

continious feedback

Agile thinking is based on building frequent feedback loops within your teams and organization. Few examples of frequent feedback loops are:

  1. Sprint demos every couple of weeks, to get product feedback
  2. Sprint retros to get process and tool feedback
  3. TDD/BDD/continuos integration to get code feedback
  4. Continuous testing to get quality feedback. Check-out our new launched 2 day extensive workshop on agile way of testing

Hurry and Read the rest of this post!

{ 0 comments }

It’s well known fact that physical Scrum Boards provide many benefits over their electronic counterpart.

With physical boards current sprint state is transparently visible to anybody in the team and to the stakeholders. As a team member you no longer are required to explain someone what exactly the team is focusing on right now as anyone can look at physical board at any point of time. Also, during standup, story-card and sprint progress get more attention than individual progress. You can setup your physical board the way you want and you don’t have to work around the limitation of any electronic tool.

card-wall

Hurry and Read the rest of this post!

{ 6 comments }

Appraisals! How many of you dread this word? This is the only time in the year that you get to bargain for salary increments, everyone end-up negotiating to their best. Appraisals are closely connected with salary raise/increments, bonus payouts and it’s feedback intent takes the backseat.

Performance Appraisal

There are three major issues with traditional approach to appraisal:

  1. Measuring and rewarding individual behaviors and contributions OVER team based measurements.
  2. Long appraisal cycle(mostly once a year) discussing both salary increments and feedback.
  3. Feedback process – Filling long appraisals forms with least discussions between reviewers about reviewee.

Hurry and Read the rest of this post!

{ 3 comments }

We discussed about committing fixed number of story points and swapping any additional scope with existing backlog in our previous post “Agile for Fixed Bid Projects“. This is a great way to maximize value with minimal change in timelines and budget. This works well when there is a trust existing between product and engineering, and client/product team understands this agile approach. Still, fixing size, undermines one major aspect of an agile team – “applying learning back into the project”. Development teams while doing size estimation give higher points where there are uncertainties and risks.  Known unknowns, new technology, unclear requirements etc. are few reasons for providing higher story points. As project progresses, teams get more knowledgeable (both technology and business) and hence some tasks now look smaller than before.

Agile Contracts

Hurry and Read the rest of this post!

{ 0 comments }

Agile for Fixed Bid Projects

by Shrikant Vashishtha August 13, 2014

The basic premise of Agile methodology is to develop software in an incremental and iterative fashion based on regular feedback that is received at the end of each sprint (i.e., 2-4 week cycle). The resultant feedback of a sprint demo often translates into change, and Agile methodology has a key tenet around embracing change. The […]

5 comments Hurry up and read the full article →

Agile Thinking: Continuous Improvement – ScrumMaster 1.0 to 2.0

by Avienaash Shiralige July 14, 2014

Readers, Our “Agile Thinking” series is focussed on bringing agility into our thinking as this helps in moving from Doing-Agile to Being-Agile. You can read our earlier article in this series Agile Thinking: Stop Starting, Start Finishing. This post talks about continuous improvement and obviously this can be applied everywhere irrespective of it is a […]

5 comments Hurry up and read the full article →

Agile Thinking : Stop Starting, Start Finishing

by Shrikant Vashishtha March 28, 2014

Limiting “Work in Process” (WIP) items is one of key ideas of Kanban. A natural outcome of it, inherently coming from Lean philosophy is to stop starting and start finishing. By having too many work in process items, it looks like everybody is busy but there is no functional outcome for the end user. So, […]

9 comments Hurry up and read the full article →

Webinar: How to Scale Agile using SAFe Framework

by Avienaash Shiralige February 12, 2014

Scrum and XP have been working well for small teams. That works fabulously for small organizations. However implementing the same for large project portfolios, having teams with 100+ developers has remained very challenging from organization perspective. There are many challenges while working with large teams like: Breaking silos/departments in large organizations Requirements focused on changes […]

0 comments Hurry up and read the full article →

Improve Sprint Throughput with “Definition of Ready”

by Shrikant Vashishtha January 31, 2014

Teams are obsessive towards better customer satisfaction and rightly so. High team throughput is one of the important ingredients towards better customer satisfaction. Before we move further, let’s look at what throughput means in business context. According to Wikipedia: “Throughput can be best described as the rate at which a system generates its products / […]

2 comments Hurry up and read the full article →