Wednesday, May 24, 2017
Wednesday, February 22, 2017
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
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!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?
Tuesday, July 19, 2016
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
IndependentStories 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."
NegotiableA 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
Dear Scrum Master, Don't let anything that's not READY into your Sprint.
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
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
What testers do in agile?
coders + testersIn 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.