The Right 3 Questions for the Daily Scrum

The common version of the questions asked in the daily scrum are:

1. What did you do yesterday?
2. What will you do today?
3. Is anything in your way?

Many teams discover a problem with these questions: They are about what a person did and will do rather than what the person accomplished. And so some teams realize there are better questions to be asked in the daily scrum:

1. What did you accomplish yesterday?
2. What will you accomplish today?
3. Is anything in your way of accomplishment?

When the questions are reworded to focus on accomplishments rather than activity, it becomes clear that the team values progress. Some individuals generate a lot of activity, but no progress. They are like a swimmer flailing about in a pool--arms flying everywhere and legs kicking furiously but without any forward movement.

Having questions that focus on what you did accomplish or will accomplish makes it clear that this is what’s important.

It’s a minor rewording, but one that will help your team succeed with agile.


This article is by Mike Cohan

"No Progress" Status in Daily Scrum

What to Do When Someone Talks About a Flux Capacitor in the Daily Scrum it mean "No Progress"


In today's world of hectic schedules, excessive multi-tasking and sharing team members across multiple projects, it is common for a team member to have no progress to report at a daily scrum.

Often, team members will try to hide their lack of progress with confusing updates: "I worked on the OrbitalMonitor class yesterday switching it to use lazy initialization for its flux capacitor all powered through an ARC reactor."

Rather than let that happen, I encourage team members to admit when they got nothing done. I do this by having team members say simply "No progress" whenever that's the case. But discuss it with your team. Maybe they'd prefer a different phrase.

There are a couple advantages here. First, it's more honest to allow people to admit when they got nothing done. Sometimes it's their own fault. (We all have days when we just couldn't concentrate.) Other times, though, it's because things from outside the project demanded our time.

Second, using a common phrase to indicate a lack of progress makes it really easy for a ScrumMaster to notice the problem. When one team member mumbles something about slight progress with the flux capacitor and another about minor progress with the ARC reactor, the ScrumMaster might not notice that both really got nowhere.

But when everyone more openly agrees to say "No progress," it becomes abundantly clear. This allows the ScrumMaster to step in earlier than he or she might otherwise and remove a problem such as an outsider interfering. It also help Scrum Master to plan the activities with no hurdles for upcoming sprints.

Whether your team uses a specific phrase or not, encourage them to be open and clear during the daily scrum whenever they have "no progress" to report. And if they do that, you'll be more likely to succeed with agile



Inspired by blog of Mike Cohn

Leave Room for Emergent Requirements

I was remembering my visit to Paris in 2012 after hearing the extremely sad news in the mean while i was searching for a current issue i was facing in my Release plan. Mike Cohen news letter give me an idea which is mentioned as:
 
Let’s suppose we’re planning a holiday somewhere awesome. Let’s make it Paris. I said awesome, didn’t I?

You don’t want to plan every waking moment of the trip. But if you only have a week in Paris, you probably want some sort of plan. You might plan on a couple of days in museums, a day trip out to Versailles, a day strolling the Champs-Élysées, and so on.

Unless you are far more anal than I am, though, you probably would not plan 10:15 a.m. to 3:30 p.m. at Musée d'Orsay, coffee until 4:18 p.m., and so on. You would leave some slack in your schedule. You do this because you want to leave time for things you’ll discover once you’re in Paris.

Similarly, we need to leave slack in our agile team’s release plans for things that will be discovered during the project.

I see product owners who look at a team’s velocity, multiply that by the number of remaining sprints, determine which product backlog items will be delivered, and then guarantee those items will be delivered. Don’t do this. Although that calculation can roughly estimate the amount of functionality that can be delivered, the product owner should not promise specifically those items.

Stakeholders and the product owner will identify new features as the project progresses. Every project of any significant size has what are known as emergent requirements. An emergent requirement is a feature that stakeholders could not have thought of in advance.

So it’s not just a feature that stakeholders failed to think of by rushing or being lazy. It’s a feature they could not think of until they saw a partial implementation of the system and went hands-on with it.

Product owners need to acknowledge these exist and will be discovered as a project progresses--just like you’ll find great cafes down hidden side streets in Paris.

And by doing so, we can succeed with agile.

Comparision Analysis on Google Analytics vs Flurry vs Mixpanel vs Kissmetrics

As per comparison analysis done for point 3 Following are detail conclusion:

There are major 3 market segments are in terms of Analytics solutions in the market.

1. Unbiased ad tracking (needs to be unbiased, i.e. keep it neutrality and not sell media) – Google Analytics/Mixpanel
2. In-app analytics - Mixpanel/Flurry
3. Media selling - Flurry

GA, Mixpanel and Flurry is based on SDK integration in the client application to log the events. All 3 support both android and IPhone. GA, Mixpanel and Kissmetrics contains the feature of A/B Split Test which help Marketing team to finalized features for implementation. GA, Mixpanel,

As per user reviews about GA, Flurry, Mixpanel and Kissmetrics contains funnel Analysis but few users mention in review that Flurry funnel analysis not work as required as compare to mixpanel.

·         Kissmetrics is focused a fair amount on e-business and little on Mobile. Friends that are web-only are happy with them.

·         Google Analytics looks like a good basic tool, but lacks most advanced features like Cohort-based analysis for Retention in terms of accuracy.

·         Flurry is the leader of the market, so it's a safe bet. It doesn't provide cohort-based analysis or the ability to dive deep into your data. It focuses a fair amount on user acquisition but doesn't have K factor, so you can't assess your virality. It also doesn't track unique users.

·         Mixpanel seems pretty exhaustive. It has cohort-based analysis, tracks individual users and allows to dive deep into your data. Apparently, it's weak on the User Acquisition side, and doesn't track any virality either. You have to pay quick though, but it's not much expensive.

Following Strengths and Improvements features in the mentioned Analytics Tool based on Users Review. It will help to conclude for decision to be taken for a final Analytical Tool for Comoyo solution.

Google Analytics Reviews	Flurry Analytics Reviews	Mixpanel Reviews	KISSmetrics Reviews	Google Analytics Premium Reviews
GOOGLE ANALYTICS STRENGTHS	FLURRY ANALYTICS STRENGTHS	MIXPANEL STRENGTHS	KISSMETRICS STRENGTHS	GOOGLE ANALYTICS PREMIUM STRENGTHS
Free and powerful	Mobile app tracking	Funnel analysis	Funnel analysis	Powerful segmentation
GA is an extremely powerful free tool that can compete with many paid analytics tools.	Effective tracking of users’ interactions with mobile apps across multiple vendor platforms and form factors.	Excellent for setting up behavior funnels with specific events you want to track by cohort with the goal of increasing conversion and retention.	KISSmetrics is great at tracking visitor progression through a specific flow. Funnels paths do not have to be pre-defined and can be changed on the fly.	Building segments and applying them to reports is intuitive. It’s very easy to build custom reports. Far more custom variables are available than in GA standard.
Visitor and conversion tracking	Benchmark data	Usability	Individual visitor tracking	Attribution modeling
GA does an excellent job of tracking where site visitors come from and conversion rate metrics to help allocate marketing spend judiciously.	Provides mobile app tracking benchmark data so that companies can compare their performance to industry norms.	Clean, intuitive user interface and strong data visualizations. It’s easy to add events to Funnels and Segmentation.	KISSmetrics is able to track known individuals across visits and devices to provide a composite view at the individual level.	A number of pre-set models are provided and custom models can be created.
Dashboards	SDK integration	Segmentation	Attribution tracking	No data sampling
The tool is very customizable, and it’s simple to set up dashboards with specific query data for sharing across an organization.	It’s very simple to integrate the SDK into mobile for both Android and iOS.	Site visitors can be segmented based on where they came from and actions they take on the site.	KISSmetrics helps users understand which campaigns drive visitors to the site so that they can optimize marketing spend.	Absence of data sampling allows the construction of statistically valid trends and datasets.
Constant improvement	Cost	Customer service	Integration	Very fast processing
The product is constantly being developed and improved with innovative new features	Free	Excellent, responsive customer service. The support team will usually respond in one day.	Ease of integration with Optimizely for A/B split testing.	Performance is excellent. Even very complex reports load in seconds.
Cost		Cost	Power Reporting and Search	Service and Support
Free		Free to $2,000 per month	Powerful Reporting on different even if you don’t know SQL. Search is power as well to find required aspects.	Although there is general agreement that the product is intuitive for an enterprise product and easy to implement, there is some difference of opinion about the quality of service and support. Some feel that it is excellent, while others have been disappointed, feeling that answers to technical or implementation questions were a bit generic.
			Cost	Cost
			From $150 to $599 per month	$150k per year for up to 1 billion hits per month, with additional pricing tiers available for higher volume sites
GOOGLE ANALYTICS AREAS FOR IMPROVEMENT	FLURRY ANALYTICS AREAS FOR IMPROVEMENT	MIXPANEL AREAS FOR IMPROVEMENT	KISSMETRICS AREAS FOR IMPROVEMENT	GOOGLE ANALYTICS PREMIUM AREAS FOR IMPROVEMENT
Overwhelming for first-time users	User Interface	Time frame restrictions	Ease of use	E-commerce tracking
Although relatively user-friendly, the sheer quantity of data and options within the tool can be overwhelming for first-time users.	One user complained of inability to see roll-up data from multiple apps; data has to be looked at for individual apps and then aggregated by hand.	There is a limit of 60 days for funnel tracking data.There are similar limitations in the Segmentation and Retention features.	While onboarding videos and resources are useful, more in-depth training is required. The learning curve is steep and users need more help to get started.	Some users say the tool is not suitable for retailers, as it’s missing some key e-commerce metrics. However, the company launched a revamp of the e-commerce capabilities in 2014.
Data sampling	Data accuracy	Data export	Barebones API	A/B testing and in-page analytics
Data sampling can be an issue for large websites with high traffic volumes.	Data does not always tally with data from vendor platforms.	It would be nice to be able to export the raw data to Excel without having to use the API. The API could also be a bit more open.	The API is functional but basic. Anyone attempting advanced customization will need lots of help from technical support.	Although users like having A/B testing and in-page analytics functionalities embedded within the tool, neither feature is robust enough for users who want to do anything beyond the basics.
Lack of update communication		Website integration	Data integrity	Custom reporting
Although the constant improvement is a plus, communication of new features or changes is lacking, which can cause certain users’ current configurations to break.		Mixpanel requires some technical skill to integrate effectively with a website.	Some users have misgivings about the accuracy of the data reported, particularly when compared to data reported by other tools.	Users like the ability to create custom reports, but doing so often requires regex, which can be difficult for non-technical users.
			A/B Testing	Online documentation
			It’s difficult to set up A/B testing without integrating with a separate testing tool. Users have to write some code using the JavaScript library.	Online training and documentation is robust for the free version, but there is little additional documentation for the Premium version.

Can a Team Have More than One Product Owner?

A Satiation i normally face during projects in my real life whether it’s OK for a team to have more than one product owner. And, if they do, what can a good ScrumMaster do about it? this Question is asked by Mike Cohen as well on his website. i found answer very logical and reasonable.

Quite simply: No, a Scrum team should not have more than one product owner.

Normally when a team has more than one product owner what they really have are multiple stakeholders. That is, two, three, four or more individuals who each have an interest in what the team builds. And usually the business has been unwilling to make one of those individuals the product owner and therefore solely in charge of prioritization decisions.

When the organization fails to make that decision, it forces the team to decide. This is entirely unfair to the team. If the organization cannot decide which one of multiple stakeholders should be the ultimate prioritization decision maker, how can the organization expect the team to make that decision?

When a decision cannot be made, it should be pushed up the organization, not down.

So, what you should you do if you’re a ScrumMaster and find yourself in the position of having multiple product owners?

Do not take on the responsibility of being the product owner yourself. Many of us are very willing to take on responsibilities that are not our own. When we do that, we run the risk of hiding an organizational dysfunctionality.

So, don’t do something like tell each of three stakeholders that they each get one-third of the team’s time. Doing that has made you the product owner, and you’ve just somewhat arbitrarily decided that each stakeholder’s needs are equal. 

So Keep your Self Calm and Scrum ON :)

What is Agile Retrospective?

Defination: An Agile retrospective is a meeting that's held at the end of an iteration in Agile software development. Retro event occurrence depend on iteration definition by Scrum Master and Team. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward.

Questions to be asked: Each member of the team members answers the following questions:

• What worked well for us?
• What did not work well for us?
• What actions can we take to improve our process going forward?

The Agile retrospective can be thought of as a "lessons learned" meeting. The team reflects on how everything went and then decides what changes they want to make in the next iteration. The retrospective is team-driven, and team members should decide together how the meetings will be run and how decisions will be made about improvements.

Environment of Retro: It is very important that Retro atmosphere of honesty and trust is needed in order for every member to feel comfortable sharing their thoughts. Norman Kerth's work at the turn of the millennium was highly important to the development of Agile retrospectives and retrospectives in general. Kerth's prime directive states, "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." Because Agile stresses the importance of continuous Improvement, having a regular Agile retrospective is one of the most important of Agile development practices. 

The Ninth Agile principle outlined in the Agile manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." A framework, such as the one below, can be used to provide structure and keep discussion during the retrospective focused.

Event Steps: Following are the Steps to do Regular Retrospective Event in Agile Scrum Project. 

1. Set the stage - get the team ready to engage in the retrospective, perhaps with a warm-up activity such as Plus, Minus, Interesting (5 minutes)
2. Gather data - create a shared picture of what happened during the retrospective (10 minutes)
3. Generate insights - discuss what was successful and identify any roadblocks to success (10 minutes)
4. Decide what to do - identify highest priority items to work on and put measurable goals on those items so they can be completed (15 minutes)
5. Close the retrospective - reflect on the retrospective and how to improve it, and to appreciate accomplishments of the team and individual interactions (5 minutes)

ref: http://searchsoftwarequality.techtarget.com/definition/Agile-retrospective