In App Billing now live in Android Market too!

This is definitely some reason for Android Developers to cheer that Android finally supports in-app billing.

What you get now ?

• You can use the service to sell a wide range of content, including downloadable content such as media files or photos, and virtual content such as game levels or potions.
• Any application that you publish through Android Market can implement in-app billing.
• No special account or registration is required other than an Android Market publisher account & a Google Checkout Merchant account. 

• Android Market uses the same checkout service that is used for application purchases, so your users experience a consistent and familiar purchase flow.

As with application purchases, Android Market charges a fee of 30% for anything sold via in-app billing, which is the industry standard. Hopefully this will help developers more effectively monetize their applications on Android Market — historically users have been less willing to pay for apps on Android than they have on Apple’s App Store.

Backlog Grooming in Scrum

In Scrum, the product backlog is the single most important artifact. The product backlog is, in essence, an incredibly detailed analysis document, which outlines every requirement for a system, project, or product. In simpler terms, it could be described as a comprehensive to-do list, expressed in priority order based on the business value each piece of work will generate. Philosophically, the scrum backlog is the engine of the business; it breaks the big-picture story down into manageable increments of work called Product Backlog Items (PBIs).

Backlog grooming (also called maintenance) is not a formal component of the Scrum process, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. (As with Scrum’s other meetings, the grooming should take place at the same time and place and for the same duration each sprint.)

Who attends the backlog grooming meeting ? 

The Team
The Product Owner
The ScrumMaster. 

What happens there?


During the maintenance meeting, everyone helps prepare the scrum backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. 

Why is this helpful?

Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined ax acceptance criteria and are estimated by the appropriate team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning always occurs prior to the SPM.

How do you get requirement analysis and design going in Scrum!

When do requirement analysis and design activities happen in the Scrum framework? How is our understanding of requirement and design analysis valuable in the Scrum framework?

Here I tried describing how these elements flow through Sprints within the Scrum framework.

Requirement analysis is one of the major activities in backlog grooming (the others are estimating and splitting). Once the Product Owner gets an idea by working with customers and adds one vague item into Product Backlog, the item will be groomed for the first time. Considering priority, this item and other smaller items are groomed through several rounds while the Team gets ready for Sprint Planning. The clarity of the items advances in each round of grooming. Acceptance criteria may be drafted in the grooming rounds before Sprint Planning. 

In the first part of the Sprint Planning Meeting, the requirement analysis continues. If you are able to continuously groom properly, the requirements will be well understood by that time. However, since items are selected in the Sprint Planning Meeting, only then is the Team sure that they are working on them. The Team normally identifies further points (e.g. exact scope, sad path scenario) to be clarified. This may be conducted by working out more details in the acceptance tests. The requirement analysis activity does not stop in the first part of the Sprint Planning Meeting, but continues in the second part and during the actual Sprint. 

In the second part of the Sprint Planning Meeting, while you are decomposing tasks, the ambiguity in requirement may surface again and be clarified. During the Sprint, test case design, modeling workshop, requirement discussion while designing and coding, and discovery from exploratory testing all contain some element of requirement analysis. Even in the Sprint Review, you will see requirement analysis activity through feedback and suggestion for improvement (new items).

When do we start design? Traditionally, we start design to move from problem domain to solution domain immediately once we get big Product Backlog items. This early move reduces the flexibility in terms of prioritization, which is not recommended in Agile development. We continue to work in the problem domain by keeping the customer orientation as much as possible while splitting the items. The splitting in the problem domain happens in backlog grooming. We also estimate the size of items in backlog grooming. Sometimes, you will have difficulty in estimating the item size, which may be caused by either vague requirements or a lack of experience. If the requirements are vague, requirement analysis in further rounds of grooming helps. If the solution is unknown, architecture or a design spike item can be added in the Product Backlog. This item is normally time-boxed, and its done criteria differ from those of normal backlog items. The output is the sufficient understanding to enable your estimating and planning. In the context of multiple teams working on the same code base, a joint design workshop may be conducted to synchronize the design across teams. In the second part of the Sprint Planning Meeting, the Team commits how much to do in the coming Sprint. In order to make the commitment, the Team normally makes the detailed plan by decomposing items into tasks and estimating those tasks. The commitment may be made based on velocity, but the Team may still think of tasks necessary for them to get the committed items done. How do you determine the tasks? You design. In the second part of Spring Planning, some teams jump into the task decomposition, and get a similar list of tasks such as design, coding, unit testing, review, and functional testing. This indicates a lack of design. How much design do we do in the Sprint Planning Meeting? It needs to be sufficient to support planning. The purpose of Sprint Planning is not design, even though there is a design element in the planning meeting. Besides, the planning meeting is constrained by a time-box, so the Team must find a way to make the best of the time. Design continues in the Sprint. The Team may organize a design workshop, or have an ad-hoc modeling discussion while coding, and coding itself is design. Our design is considered done when the item is done.

In conclusion, you can see the value of requirement understanding and design in the following Scrum activities (major ones in bold).

Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review

Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done

This flow allows for requirement analysis and design within the Scrum framework.

Guidelines for Entrepreneurs and Innovators

Thought to share this great article with all am sure some of you may be already following Harvard Business Review , if not have a look at this link

Scrum : Having fun is a serious business

Imagine if our days at work were filled with laughter and imbibed with a feeling of camaraderie and an edge of excitement. Imagine a workspace that harked back to playgrounds of childhood where invention and innovation were a natural part of every interaction. Imagine being responsible for your own environment, your own pace and your own workload. And imagine delivering high quality work frequently to delighted, relaxed customers.

You can turn that imagination into reality. There is a simple and well-understood mechanism for getting from wherever you are now to where you would like to be, and no, the mechanism is not Scrum.

It is You.

More specifically, it is the interaction of your moving parts: body, mind, heart, spirit, and your personal relationship to those you work with.  Successful product development comes from happy, impassioned individuals, and highly motivated, energized teams.

So how does Scrum help?

Scrum will offer you structure and boundary conditions to contain and guide your innovation. Contrary to common usage, Scrum is not a methodology or a process. Scrum is a framework for building new products, or guiding a complex project, it is not a formula for success, and it most certainly isn’t the next ‘silver bullet’.

Scrum represents a movement away from hierarchical command-and-control systems towards trust and self-organization.  Scrum is rooted in the principles of Complex Adaptive Systems and Object Technology.It consists of a few core rules and practices, which although very simple are utterly essential.  Each rule and practice is part of a synergistic whole, and to drop one part is to destroy that synergy. Half measures avail nothing.  When the rules of Scrum are rigorously followed a process will emerge that is suited to your own context.

Scrum makes one promise only: it will help you fail in thirty days or less. That’s it.  And it will begin to surface organizational dysfunction in the process.  Healing from that dysfunction is up to you.  What Scrum can give you is a space to be human, to try, to fail, to reflect and to try again. Putting the simple Scrum framework in place at your organization will be the first step towards creating an environment of safety and trust, an environment of empowerment and ultimately of innovation and success.

Scrum is not those things, it is simply a structure which will allow those things to emerge, rather like a bamboo frame allows a tomato plant to bear fruit. It is the people — you and your team mates and your managers — who will make the changes that lead to new behaviors and ways of thinking. An organization seriously investing in Scrum will find within that simple framework its own methodology. It will discover a set of practices best suited to optimize return on investment. It is the people, not the process that will create a happier work environment.

Remember, Scrum is not a rigid methodology; it continues to evolve, to adapt. Similar to the game of chess, there are some clear and simple guidelines to follow, but once those guidelines are understood –and practiced– a multitude of Scrum implementations are possible. Most importantly, Scrum is context-dependent and the needs of the orgaization should drive the implementation. There is no formula, no set of steps to follow. The wonderful paradox here is that Scrum does not tell you how to do Scrum.