Wednesday, February 22, 2017

Definition of Done

Dear agile team, Don't let anything that's not DONE into your production.

In this practical and dirty world of software development, many roles work together on a user story and do their tasks to complete the user story. For a role, when s/he finishes his tasks, s/he might think that s/he is done. But we need some tool which will help the team and the product owner to get the confidence that a user story is really "Done" Done. With different members doing work that is "finished" at different times, how can the team and the Product Owner, know when a story has truly been completed?

Definition of Done (we will call it DOD henceforth) gives a confidence to the team and product owner that the story is done and can be released to production any time. Definition of Done is a list of things that must be finished before the work/story is accepted by the Product Owner. Merely testing the acceptance criteria can not ensure that the story is done. Acceptance Criteria is just a part of DOD. DOD also has lot of other things like -

Wednesday, August 3, 2016

Are we burning the right thing?

Is our development effort aligned with the business?
Are we getting good value out of our development team?
Is our team working on the right items?
Are we on the right track to get more value out of the team?
Are we burning the right thing?
Product Managers get a severe headache when these questions bang-bang their minds. Our development teams are usually great and great teams can deliver great software, but when the software delivered isn’t of high value the Business (i.e. the Product Managers) will still not be happy!

Tuesday, July 19, 2016

INVEST in user stories and perform SMART tasks

What is a good user story?

In scrum, we get married to user story. Have you ever thought of which story is good to get married and which is not? What are characteristics of a good user story? The acronym "INVEST" can guide you to identify the good stories:

I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable


Stories are easiest to work with if they are independent. Its better for them to neither overlap with nor depend on other stories and we should be able to schedule and implement them in any order.
We can not always achieve this. Once in a blue moon, we may say things like "3 points for the first screen, then 1 point for other screens."


A good story is negotiable. It is not an explicit contract for features. The details will be co-created by the customer and development team during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories.

Monday, July 4, 2016

Definition of Ready

Dear Scrum Master, Don't let anything that's not READY into your Sprint.

Imagine, you are going to cook a meal for your spouse for your anniversary evening. Before starting to cook, you actually check, whether all the ingredients are available, you check if those are in the sufficient quantities, you buy out the missing things and then you start cooking, Right? The same is true for user stories.
User stories after their birth, have very tiny details. It is difficult for the team to commit to such stories. Team needs discussions, analysis, arguments and negotiations to groom the stories, so that the stories become matured and then team can commit to the stories.
But how does a team know, if the story is really ready to be taken into the sprint?
As user-story becomes clear and team doesn’t have any unanswered question and dependency remaining, the story is considered "READY". The list of items which help us to identify the "READY"ness is called as Definition of Ready (DOR).

Every user story must satisfy the INVEST criteria, before team commits to it. Every dependency
from the story needs to be removed, before team commits to it. All the necessary softwares and hardwares must be ready, before team commits to any story. These and many more items comprise into a list i.e. DOR.
Before committing to any story, the team can check if the story meets all the DOR criterion. If not they can reject the story, so that the stakeholders can put the missing details into it.
Agile promotes "Courage" as its core value. Courage to say "No" is important while committing for the stories. DOR gives us the sensible reasons to say "No".

Sunday, June 26, 2016

Testers role in agile

What testers do in agile?

coders + testers

In a perfect agile team, there are no people called as developers and testers. Entire team contributes to development and testing. So this article is non-existent in a perfect world. But in the real world, where developer (actually coders) and testers were in existence before agile came, this article finds a valid place. Development team does not mean coders. Software development comprises of coding and testing. So till now, we were mistakenly calling the "coder" and "developers". My view is "developers" = "coders" + "testers". So when we say development team in agile, we really mean coders and tester and any other roles which are required to achieve the say do ratio.
In non-agile environment, the role of a tester includes analysis, test case design test case writing, and test case execution. He is involved right from the project initiation stage up to when the project is closed.
However, in agile environment his role primarily is to work as part of a development team, and to ensure that quality is built into a product by working closely with the product owner. This helps the tester get more details out of the story cards. It will be difficult for the development team to meet the acceptance criteria and consider a story "done" if the tester does not engage him/herself with the product owner. The role of a software tester in an Agile environment goes beyond “just testing” and logging bugs.

Monday, June 6, 2016

How I passed PMI ACP exam

Dear Friends,
I will give you some tips and hints to help you complete you PMI ACP i.e. Agile Certified Practitioner exam in the first go.

Step 1) Real life experience:

I agree with PMI's criteria that we need to have 1500 agile project experience. It gives you good knowledge about how things can go right or wrong practically. So if you do not have that real life experience, then please get it. It really helps you to solve atleast 20% of the PMI ACP exam questions.

Step 2) Classroom training:

This 3 day training was also important to know some unknown things in agile, lean and kanban.

Step 3) Books:

My main study guide was the book from Mike Griffiths: PMI-ACP Exam Prep. I read it three times.
First I read the book in fast pace. I focused on headings and diagrams. After reading each chapter, I also solved the exercise at the end of the chapter. For the first time I got only 50% answers correct.
Second time I read the book in full details. I also carefully read those sections, for which I got wrong answers in the first time exercise. Then I solved the exercise and this time I got 70% correct.
Third time I read the book with 100% attention to each and every word. (remember to read each and every word) Now, this time I got 100% correct answers when I solved the exercise (may be because I would remember the answers by then).

Step 4) Solving the online exams:

Each time I completely read the book, I also solved questions from below links. Some of those are free and some of those are paid. I recommend to solve free ones first :) Paid ones are also equally worth. Paid ones cost you from $3 to $10, which is worth than not doing it & putting $495 at stake. From free ones, I got approximately 20% similar questions in my exam. From paid ones like examprofessor, I got approximately 30% similar questions in my exam. edward-designer link is like a composite of all the online guidance. Remember the questions are not exactly same. Those are similar and you will get fair idea of the difficulty level and also you will get to know your gaps.

Step 5) During the exam:

First read the question carefully and understand grammar of it. If it is easy, solve it. If you are in doubt, mark it and go to the next question. After you solve all easy ones, solve the marked ones. This should leave you with 30 minutes. Now in those 30 minutes, review carefully each answer of all those 120 questions. I am sure you will change answers of at least 5 questions (because your brain keeps on thinking).
Out of 120 questions, I was able to solve 80 questions with ease. Those werevery straight forward (based on my knowledge and experience). 20 questions were little tricky, but if you think twice, then they were reasonable. Rest 20 were very difficult and I had to spend 1 hour to solve those.... and I am sure I might have scored 0 in those 20.
Suggestion: Apart from the suggested book above, also read other books on lean, kanban and XP. Also browse one website related to these topics daily. This will help you to solve those 20 tricky questions.
Best of luck!