On a number of occasions i have come across the issue with Agile Story Points and how the final software output is measured. Though there is no best way to measure a software delivery but a lot of experimentation has been done in the recent years. In this post i will be sharing some of my personal experiences and will try to highlight the Agile Metrics and ISO Standard Measures. I personally feel, both of them can be mixed together to a certain level to measure the output. 

Without a doubt Agile processes and procedures have brought advantages for speedier delivery of software  that  meets developing client needs. Be that as it may, the opportunity given to individual teams to manage their own processes has made it difficult to manage the activities across Agile teams – what we call managing ‘Agile-at-scale’.

​To be specific, Agile metrics such as Story Points, may be used by individual teams to manage their own affairs but are very little help for the tasks of planning and monitoring progress across teams, for understanding performance and whether it is improving or not, and for estimating future investments.

Senior management is responsible for setting budgets and allocating resources optimally so as to deliver the greatest value to the organization, and for tracking progress against budgets across the organization. This cannot be done properly for a software group using only typical Agile processes where there are no common performance data across all the teams. These management tasks become even more difficult for an organization that has contracted out its software development to external suppliers that use Agile processes, but that do not use any standard performance measures. I have come across a number of organizations who lack in defining individual, team and product level KPIs to achieve a target - though they do achieve something but not precisely hitting the nail with the hammer.
​
In this post i'll try to explain the challenges that management faces when confronted with the limitations of Agile metrics. I'll try to show some of the stuff which has been experimented, how simple but effective and long-established ISO standard software measures can fit seamlessly into Agile processes to enable managers to estimate and control Agile delivery at scale. This can be achieved without needing to change any of the underlying Agile processes, and whilst continuing to obtain the benefits that Agile teams can bring in the speed and flexibility of delivering business value.

Migrating to a new version of SharePoint is like moving to a new home.

Before you make that move, there are critical issues to consider. Will the furniture, appliances, and decorative pieces from your previous home fit and work in your new home? What about the custom furniture in your current home that you may not be able to move? For example, it is difficult to move built- in closets that you had a contractor build for you. On a similar note, when was the last time you looked through all your drawers and found just how much useless junk you’ve got hiding in there?

Similarly, a SharePoint migration requires careful planning to identify the critical issues and mitigate the risks of the migration. Whether you’re moving your environment to SharePoint 2013, SharePoint 2016, or SharePoint Online (SPO), it is essential to understand the limits of your new environment, and whether all your content meets these limits. It is also important to consider whether content that is outdated, no longer in use, or forgotten, is worth moving.

It is also important to understand that SharePoint customizations such as custom web parts, custom features and solutions, and custom Master Pages and Page Layouts, do not work in newer versions of SharePoint. Some custom work will be required to move those customizations, especially when the destination is an SPO server, which supports SharePoint Apps and sandboxed solutions.
​
Which is why an analysis of your current environment and careful migration planning can save you time and money, and aid in the optimization of your new SharePoint environment.

​Custom Master Pages, and their associated page layouts, cannot simply be migrated over from SharePoint 2007 or 2010 to SharePoint 2013. While the formatting of Master Pages is similar between these versions, it is not the same, and Master Pages written for one version do not work in any of the other versions.

It is vital to know how many custom master pages you have and what they are, before migration, so that you know which of these you either have to discard, or rebuild to work with Office 365. Once these pages have been rebuilt, you can easily migrate the content directly from the old version of the page to the new version using both the OOTB Upgrade and 3rd party migration tools.

Its best to work with SharePoint UI implementation experts to implement new versions of Master Pages and Page Layouts, and not assigning this task to SharePoint developers, who specialize in a completely different skill set (Visual Studio development vs. HTML and XML) and tool sets (Visual Studio and SharePoint Designer respectively).
​
In addition, i would recommend working with graphic designers to create the look and feel of the Master Pages (usually using Adobe Photoshop® or similar tools), and have the content generated by those tools given to the SharePoint UI implementation experts. Most SharePoint UI experts are not graphic designers, and won’t necessarily create good designs even if they know how to implement designs created by others. Similarly, most graphic designers know how to design beautiful web pages, but are not familiar with UI implementation in SharePoint.