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