Google to launch Android Pay at I/O Developer Confernce

Google is set to officially launch Android Pay during Google I/O conference. Android Pay will allow businesses to add mobile payments to their apps, to which users can upload credit card or debit card information.Using the API, developers can enable tap-to-pay transactions leveraging the Near Field Communications (NFC) feature on the  Smart Phones.

Cortana on Android and IOS

Microsoft is bringing Cortana to IOS and Android. Cotana is the Microsoft's version of personal assistant, which is similar to Apple's Siri and Google Now.Microsoft’s phone companion will help Windows 10 PC owners find relevant apps on their Android, Windows, or iOS phones to make use of OneNote, OneDrive, and many other apps and services.

Android Muffin (6.0) expected to launch in Google I/O conference

There are reports that Android M will be launched in upcoming Google I/O conference. Given the fact the Android Lollipop has only 10% adoption so far, OS launches are going at much faster space.Just look the fragmented adoption of Android OS versions,

IOS 8.3 released

Apple has released IOS 8.3 release. One of a major feature is they have added 300 new characters to the emoji keyboard that offer racial diversity. There are lot of performance improvements in the areas of app launch, app responsiveness, messages, WiFi etc, the things that are commonly used. And of-course ton of bug fixes as well.. It will be interesting to see adoption rate for this version of the OS..

Android Material Design Apps

One of the big improvement with Android Lollipop is the introduction of material design concept.
Here is the community forum where people are showcasing apps designed around material design concept..
https://plus.google.com/communities/108905768919281054977

Scrum meetings - By developers or user stories?

What is effective in Scrum meetings? Going over by user stories (assigned for that Sprint) or going over by developer?

In the case of user stories, you go over the all the user stores assigned for that Sprint, check the status with the developers & QA assigned to that user story and identify any blocking issues.

Another option is to just go from one developer to another and ask him what he is working on.

I feel doing scrum meetings by user stores is more effective as it helps to track the story better and identify blocking issues. Just going over what developers are doing one by one doesn't convey the whole picture.. 

Sprint Planning

As a Product Manager, Sprint planning is a balancing act. It is finding a right mix of items from,

Feature Backlog - Maintaining a active list of feature backlog is critical. The input to this list could come from variety of sources - Customer feedback, Competitive Gaps, Product Roadmap, Engineering feedback etc. Prioritizating the feedback in terms its impact and cost will be helpful prior to sprint planning.

Backlog Bugs - Active bug list is just the nature of software development process, again it is important to keep the bug list prioritized so that it can be appropriately assigned to a sprint.

R&D - A sprint activity cannot be just development of new features and fixing bugs. Certain activities require investigation and may not end with something that is shippable in the sprint.

Out-of-scopes - These are unplanned feature requests or changes that have solid business justification. Again this is the nature of software development process to have change requests come in during the middle of development.

Now let us look at allocation for the above. The allocation may vary from kind of products, but this is the model that I follow,

Feature Backlog - 50%
Backlog Bugs     - 10%
R&D                   - 10%
Out-of-scopes     - 30%

The next step is looking the team capacity. This is simply number of  developers & QA available for the Sprint cycle. As an example, if you 10 developers and 5 QA available and the Sprint cycle is 2 weeks, the total available capacity is 30 man-weeks.  Now spread this capacity as per the allocation model above,
Feature Backlog - 15 man-weeks
Backlog Bugs     - 3 man-weeks
R&D                   - 3 man-weeks
Out-of-scopes      - 9 man-weeks

Now go back and estimate the cost (man-weeks) of the prioritized feature backlog. Then it becomes easy to decide which features can fit because we've already estimated the allocation for new features.