How can we get the best Estimates of Story Size ? 

                                                      

Mike Cohn has written it beautifully and mentioned three key points to remember in order to Estimate :

• Keep estimates manageable.
• Estimate in relative terms.
• Bucket backlog items by story size.

I really liked the article. 

How can we get the best Estimates of Story Size ? 

A Discussion on how Agile Management is different and beneficial from the other management techniques 
you can read and follow the discussion here   its on LinkedIn

Reality Check !

Agile Product Ownership - A quick Revision

Agile Product Ownership: Quick and Simple 

An amazing video that says! all..
Watch the video here

Choosing a sprint length..How much is enough ?

Agile Pain relief :  Choosing a sprint length!

a very nice article that explains really well, how short iterations are benefits over the longer ones. However, as said, its again project dependent and how it suits you the best..
Read the article here

How to Split a User Story

I really liked this article, so thought of sharing it here on my blog...
Courtesy : Richard Lawrence
A flow chart guide on how to split a user story

I hope you find it useful :o)

Retrospectives : the most challenging part of the scrum life cycle can be made easy with "TRUST" in the team 

In the scrum life cycle I believe retrospective is the most important and challenging part as this is the stage in the iteration, where people have to say their heart out and let the team know how do they feel about the iteration that went by ? what according to them went well? what went wrong? what is that they still would like to continue? What is that they think was a blocker and should be stopped( it may be a tool /process etc.. ) This is the stage where we know how to further improve ourselves continuously taking the feedback from the team. What is there that we have still not tried and can bring wonders to the team environment and hence further increase the quality of work and may affect the velocity as well!! This makes it critical for everyone to understand that it’s the time when all the members need to speak with no hesitations in mind, otherwise retrospective will lose its purpose, everyone in the team should take it as a sacred ground to share what they feel.

Its human that people usually don’t want to add or say things at first go thinking that someone else will add that point and why should they( WHY ME ?) , especially if there is a negative feedback to share or a point that he /she did not  find comfortable with while working during the iteration. It is obvious that people only speak in retrospectives when they feel that they are safe…

Here is where “TRUST” comes into picture, unless and until team members will have a trust on each other in the team, retrospectives can’t be successful! It is important that people understand and are sure of the fact , that even if they share something negative about a specific thing in the iteration, it will be taken in a healthy way by the other team members and the everyone will try to find out a solution for the same as ONE TEAM or maybe someone from the team would present it in a way that the misconceptions are resolved about a specific theory.

There are histories of project tumbling over in spite of the fact that they had the most technical people in their team and one of the key reasons shown up is NO TRUST amongst them.

Building trust amongst team members though is not very easy, but the most important task to be performed and the Scrum Master plays a vital role in it. He is the one who is responsible and ensures that team and its environment is healthy.

Here are some of the symptoms shown by such teams with decreasing trust amongst its team members:

Members will stop taking initiatives

Negative vibes in the team everywhere

Members are disinterested what others say during the daily scrums

Members will stop to provide their inputs during retrospectives

It is very important to sense these symptoms on time, and the corrective actions also need to be taken.

Team building exercises have proven very helpful, in such scenarios, group coffee breaks and lunches is also a good option … Involving people in trust building exercises is also a solution … It is very critical to understand here that we all are humans and feel bad of personal negative comments passed by someone , at this point scrum master needs to intervene to make the situation light …these are very sensitive issues and it’s the time when he explains to the members that lets not miss the opportunity by the means of retrospective to know each other better rather than getting into conflicts…

Since retrospective is the time to be happy as we successfully reach at the end of the iteration, it can be celebrated, team members can join for a retro supper..

“thanks to you” is another event that can be very motivating for the individuals in the team, when they receive a thank you note from someone within the team for the tasks performed during the iteration or help provided, or from higher management..

Also there are no rights and wrongs for the retrospectives. You just can’t copy the exact template of it from some other project as your team is another unique set of members and every other rule may not apply. As Agile always emphasize on the fact that you can’t force upon on team, similar is the case here... do as you think is most fruitful to you maintaining the TRUST... 

WHY  Personas are important in Agile World 

In your day to day testing activities, think , how easy it would be if in addition to, how to test and what to test, you also know “for whom to test”?

It really eases the job , when you know the person who will be engaged with the application / software for whom you are testing as a tester ?

When we create personas, we not only understand the role of the person at the customer site, but also try and understand the characteristics of a person.

• -         His name, his photo( how does he look like).
• -         Lifestyle he follows?
• -         What kind of personality that person holds?
• -         What frustrates him while working on the application?
• -         What makes him really feel good about the application?
• -         What is that feature that best suits his daily routine of Job?
• -         How techie is he ? what will be a real help to him ( if added as a new feature) ?
• -         When does he access the application and how ? How much time does he spend on the application ? etc.. etc..

However this is the point where you need  maximum co operation form the customer, and he has to understand or in other words we need to make him understand the importance of the persona creation, Coz they are best people to provide us with such data.

There are examples from various projects who have implemented this and got fruitful results, with this approach.

Just imagine if you know that a person who uses your application is a super busy guy and wants to access the application for let’s say only 10 min in a day but those 10 mins are very critical for him to get all the details, and he has not a second to waste. You would obviously make sure in such a situation that you must have test cases related to the response time/performance  and the screen refresh as a person can’t wait for a longer time to get the results.

I implemented a similar thing in my project. Fortunately for us it was easy to create personas , as in my project we also had our Personal Support Officers sitting at the customer site and we had explained the whole scenario(need to for personas) to him and wanted him to convey the same to the representative from customer’s end. We then had a meeting with a customer’s representative who wanted to participate in the activity.

We created a persona template and requested it to be filled in by the key people who will working on the application.

Template included fields like :

• -         Name
• -         A casual Picture
• -         Age
• -         Sex
• -         Hobbies
• -         Education background – Last Degree
• -         Work designation
• -         Work profile
• -         Time spent daily on the application
• -         Your need from the application/ your current challenge
• -         When do you start your work?
• -         Do you ever stop your work ;-) ?
• -         Any other detail that you would like to share

At the end we had a list of key people accessing our application and from the technical department to their Administrative staff.

In this process we got to know many interesting facts about various people using our application which really helped us creating our test base according to their needs.

e.g . we got to know there is a person at the customer site called Mark 23 years of age,who is very technical ( understands the application well) and has the busiest schedule, he starts his work, the moment steps out of his home. He likes to access  few details when he is still in metro on his palmtop. This made us really focus on the screen fit tests for the application. If the GUI looks perfect or not and many other details ?

And there were many such cases and their respective preferences, which made us write some customer specific test cases and we ended up having even more satisfied end users. 

I liked implementing it and hope you will also ..:-)

Best Example for the User Story and its Estimation

Best Example for User Story and its Estimation

Requirements

Requirement Gathering is I believe the most difficult task and to put the requirements in user stories so that others understand them is even more tricky. When I say others I mean the developers who will develop them as well as the testers who will work on the developed features.

 I have been facing the same issue at work and I am very sure many of us do when we read and understand the requirements in the form of user stories. In case of specific customer scenarios sometimes it is challenging for us to relate it to the practical usage that will happen @ the customer site. How will he use it, who will use it, what could be the possible conditions/pre conditions...
Sometimes it does happen that you come accross a customer scenario which is difficult to understand and visualize. In those situations if the requirement is written with : Given-When-Then it really helps.