In Part 1 we extensively covered   the basics about Scrum, Agile Manifesto , the Principles, facts and myths about Scrum and the roles within the team. 

In this post we will concentrate on understanding  and will do a deep dive analysis of:

- Scrum Events
- Scrum Activity - Backlog Grooming
​- Scrum Activity - Slack

Scrum events are designed to enable critical transparency, inspection, regularity, and adaptation. You must prefer to use these predefined meetings with fixed objectives and maximum durations instead of ad-hoc meetings, which most likely waste our time.

There are just five events in a Scrum Project:

1. Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four other events (as represented in the above diagram), development effort, and the maintenance of the Product Backlog.

2. Sprint Planning: Sprint Planning is the first event inside a Sprint. The Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them.

3. Daily Scrum: The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed. During the Sprint, the Development Team holds a daily meeting (normally 15 minutes) to coordinate the work for the next 24 hours. This meeting is called the Daily Scrum.

4. Sprint Review: Before the end of the Sprint, the Development Team presents (demonstrates) the outcome of the Sprint to the customer and receives feedback. This meeting is called Sprint Review (also known as Sprint Demo).

5. Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint. This meeting is called Sprint Retrospective.

Time Box is an essential concept in Agile methods, a predefined fixed maximum duration of time in order to maximize productivity in which we freeze the target and work with full focus on certain tasks or objectives. Time-boxed events  repeat many times, until the final goal of the project is achieved. All the changes are applied only when one time-box is finished and we are ready to start the next one.

The duration of a time-box should be agreed upon and fixed. We are free to change the duration based on lessons learned, but not frequently, and never based on single occasions. For example, we are not allowed to say that “we have a lot to do this time, so let’s increase the duration for this particular case”.

What we are allowed to say is “based on the previous ten time-boxes, we realized that the duration of our time-boxes is not suitable, and a 30% increase in duration might better fit our needs. So, let’s increase them from now on”.

After some thought i have decided to write and share some of the basics about Scrum. A lot of people have different views, theories and ways of doing things which they call Scrum. While i do not contest some of those practices but its essential to understand the concepts and strongly agree that every organization team will need to mold and churn some process to make things work. 

So in this series of blogposts, the first one will be addressing the following:

- Scrum and Agile
- Agile Manifesto
​- Agile Principles
- When to use Scrum VS other Methods
- Facts and Fibs about Scrum
- Scrum Timeline
- Scrum Roles and Team

At a later time, i'll share the more advanced stuff and also touch base with SAFE.

It is not possible in some projects (especially in IT projects) to gather all the requirements upfront because of their extreme uncertainties. Therefore, we need a project management method flexible enough to deal with many change requests that appear during the project and keep the project team productive.

There are a number of systems designed to provide these two properties, and a group of them are called Agile Frameworks. Scrum is a project management method of the Agile group; it is the most famous and the most broadly used one.

Scrum is based on a certain process, which i'll explain in the next few blogposts as we progress. This Scrum process will not be effective, unless it is combined with certain roles and artifacts.

Given the diversity of operating systems supported by Docker and the differences between .NET Framework and .NET Core, you should target a specific OS and specific versions depending on the framework you are using.

For Windows, you can use Windows Server Core or Windows Nano Server. These Windows versions provide different characteristics (IIS in Windows Server Core versus a self-hosted web server like Kestrel in Nano Server) that might be needed by .NET Framework or .NET Core, respectively.

For Linux, multiple distros are available and supported in official .NET Docker images (like Debian). In the image below  you can see the possible OS version depending on the .NET framework used.

You can also create your own Docker image in cases where you want to use a different Linux distro or where you want an image with versions not provided by Microsoft. For example, you might create an image with ASP.NET Core running on the traditional .NET Framework and Windows Server Core, which is a not-so-common scenario for Docker.

When you add the image name to your Dockerfile file, you can select the operating system and version depending on the tag you use, as in the following examples:

I have come across this issue of Date and Time  in SharePoint that i feel like writing an email to Microsoft for making this the most confusing thing ever . 

When you create a Date column you have the choice of Date and Date & Time.

Note the keyword “Format” in that option. Even if you select “Date Only”, your users can still type, or copy and paste, a date and a time and it will be stored as a date and time. But… only the date will be displayed.

After considerable amount of wasting my effort and countless guess work, i came to understand that Times are represented as parts of a day.

You should use .NET Core, with Linux or Windows Containers, for your containerized Docker server application when:

•  You have cross-platform needs. For example, you want to use both Linux and Windows Containers.
•  Your application architecture is based on microservices.
• You need to start containers fast and want a small footprint per container to achieve better density or more containers per hardware unit in order to lower your costs.
  

In short, when you create new containerized .NET applications, you should consider.NET Core as the default choice. It has many benefits and fits best with the containers philosophy and style of working. An additional benefit of using .NET Core is that you can run side by side .NET versions for applications within the same machine. This benefit is more important for servers or VMs that do not use containers, because containers isolate the versions of .NET that the app needs. (As long as they are compatible with the underlying OS.)

You should use .NET Framework for your containerized Docker server application when:

•  Your application currently uses .NET Framework and has strong dependencies on Windows.
•  You need to use Windows APIs that are not supported by .NET Core.
• You need to use third-party .NET libraries or NuGet packages that are not available for .NET Core.

Using .NET Framework on Docker can improve your deployment experiences by minimizing deployment issues. This “lift and shift” scenario is important for containerizing legacy applications that were originally developed with the traditional .NET Framework, like ASP.NET WebForms, MVC web apps or WCF (Windows Communication Foundation) services.

Plenty of people have written on this topic and  i'll try to clear out some misconceptions about how you should go about it. Moreover one needs to draw a very clear line about Migration and Upgrading since they are both different which a lot of people seem to mix up. On a lot of forums i see people asking questions like how do we migrate from SP 2007 to SP 2013 and then to 2016?  Another question which is quiet frequent relates to SharePoint 2010 license and if its possible to do a direct migration from SharePoint 2007 to SharePoint 2013.

The issues can be resolved easily and it is not that difficult as it looks like. You only need to go through the post with full attention. So, let us get started.

Oftentimes, it happens with the users that they are currently using SharePoint 2007. But, as the advent of new features and technology, they think of SharePoint to SharePoint migration. Although, it is believed by many users that it mandatory to switch from 2007 to SharePoint 2010 and then, further proceed towards SharePoint 2013 migration. However, it is not true. This post deals with the best possible solution for moving from SharePoint 2007 to 2013 and also gives a chart to show the benefits of SharePoint 2016 and why you should consider it.

I have written very extensively on the topic of Migration to SharePoint Online, in case you are looking for it. 

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.

I​n the past, solution delivery was oriented around the waterfall model. Development and delivery of applications was typically divided into many separate steps, such as gathering requirements, writing code, packaging, performing tests, installing the software, etc. Each step was typically owned by one team, which was responsible for only that part of the process, ignoring others.

In other words, developers were focusing only on code development, a process that could last months or even years, leaving solution delivery to the operations teams. New solutions and changes were implemented as one-off revolutions, which required heavy planning and change management processes. This approach had many drawbacks. It didn’t scale well, nor was it immune to quickly changing requirements. It didn’t promote cooperation in solution delivery but promoted competition and blaming others. Any mistake made at the beginning of analysis was stuck with a project until its conclusion, and in most cases entire solutions were
becoming obsolete even before they started yielding any benefits.

The DevOps methodology addresses organizational issues related to the software production process. Since it comes directly from the agile movement, it promotes incremental, iterative solution delivery. DevOps is not about a dedicated team nor is it governed by a well-defned set of rules or tools. 

After being in preview for quite some time, Azure Storage Explorer is now available in general availability (GA).

You can get it from:

• For Windows https://go.microsoft.com/fwlink/?LinkId=708343&clcid=0x409
• For MacOs https://go.microsoft.com/fwlink/?LinkId=708342&clcid=0x409
• For Linux https://go.microsoft.com/fwlink/?LinkId=722418&clcid=0x409

With Azure Storage Explorer you can directly access your Azure Storage from your preferred client to download/upload content, manage you blobs, files, queues, tables or even your Cosmos DB Entities.

To connect to your Azure tenant (covering all public, government or China) you can use either your credentials, a connection string or shared access URL or the storage account key.

​You can add multiple accounts to connect to your Azure Storage using the View\Account Management menu.