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

Upfront Thinking Is Like Insurance

Insurance is great for all sorts of things. I have health insurance in case I become ill or injured. I have auto insurance that will repair or replace my vehicle if it's damaged. It also protects me in case I am involved in an accident that harms someone else. I have life insurance so that if I die, my wife and daughters are taken care of.
These are types of insurance I've chosen to have. There are other types of insurance I've also chosen not to have. For example, I've personally chosen not to have dental insurance. Most years that works out great for me. But there are some years when I have a big bill and wish I'd paid for the insurance. But, overall, I've been happy with that decision.
Similarly, every time I buy a plane ticket online there's a little checkbox asking if I want to buy travel insurance. I think it covers me in case I get sick right before a flight or something like that. I've never bought that and I've never regretted it. I've also flown over 2 million miles. So forgoing that type of insurance has also worked out well for me.
So insurance is great. I can't imagine going without my health insurance. But other types of insurance can be thought of as calculated gambles, which is exactly what they are. And sometimes those gambles pay off, sometimes they don't.
We can think of upfront thinking on development projects in the same way we think about insurance. Like insurance, upfront thinking is a way of paying a little today to avoid paying a lot tomorrow.
Upfront thinking on software projects can take a number of forms. It can be someone thinking about the architecture of the system. It could be a UI designer sketching wireframes. It could be an analyst building detailed scenarios and confirming all manner of edge cases conditions through workflows. Or it could be a database designer thinking about the structure of the database. I'm not saying any of these are bad (or that they're good). They are merely examples of upfront thinking.
Some projects will benefit from some amount of upfront thinking (although perhaps not all forms at once that I've just listed), just like many of us benefit from having some types of insurance.

How Much Upfront Thinking Is Enough?

An important consideration is how much upfront thinking is enough. The best way to determine this is, unfortunately, in hindsight. But use the level of upfront thinking you do on current projects to help you decide how much to do on future projects. Here's how ...
Suppose your team finishes a project and they never had to reverse a decision. Every decision was made perfectly the first time. I'd say that team overinvested in upfront thinking. They over insured.
Consider instead a team that finishes their project and only had to reverse one decision. But it was a major decision and caused a total re-architecting of the system. That team underinvested in upfront thinking. They underinsured.
Finally, consider a team that finishes the project and had to reverse a lot of little decisions. None caused big re-architecting, but there were a lot of little decisions that each caused rework. On their own, each is small. But added together, it was a lot. Again, here's a team that underinvested in in upfront thinking. They were under insured.
So, as projects progress, evaluate whether the team is having to occasionally backtrack on decision and architectural decisions. They should occasionally have to do so. If they never do so, they've over invested in insurance by doing too much upfront thinking. But, if they're backing up too much or in big ways, they have underinvested and should do more upfront thinking.