The Importance Of Sprint Planning

Sprint planning is the first ceremony in the SCRUM cycle. I’ve seen varying implementations of sprint planning depending on the client I’m working and often it works very well. Occasionally however, I have worked with clients where the entire team including the management decide to prioritize it under everything else.  For me this just screams tragedy, so here comes my perspective on the importance of sprint planning.

Wait…I thought I was the striker?

A team without sprint planning is kind of like a football team without a tactics drill session and game strategy.  You could knock a team together, buy the kit and then when it comes to the first game everyone is running amok the entire time.  I’ve seen this happen in scrum teams.

Dedicated time assigned to planning allows the team to focus on the business requirements. This is the time where gaps in requirements are raised, misunderstandings are brought to the surface and most importantly solutions are created as a team.

Let me just get on with it

Often without planning, developers will start coding immediately in isolation without taking into consideration the other in-progress user stories.  Potentially these clashes don’t appear until much later in the sprint and then there is a rush to refactor code conflicts and address requirement conflicts – This increases exponentially when there are more dependencies between stories.

Isolated developers will also create solutions using patterns best suited to their experience.  If not agreed upon within the planning session, you will find similar & related business requirements implemented in several different ways. These can result in increased code duplication, complexity in refactoring and adding to technical debt.

Suck it up princess

From a moral perspective, sprint planning is an excellent time to get the team on the same page.  The team decide which user stories are committed to the sprint – not the lead developer, not the product owner…the team.  The sprint is delivered as a team,  so commitments must be made as a team.  By allowing the team to decide what can be delivered will give a sense of responsibility and ownership.  I have often found teams that feel this, will achieve more and higher quality.

Some managements will try and push more into the sprint at the beginning and this only creates negative feeling and lack of control.  The team must feel the committed stories are achievable else efficiency will suffer before the sprint has even started. Remember more back log items can always be added to the sprint if the team is achieving and capacity across all roles is there.

Incomplete work from the previous sprint can also tempt developers to skip the session in the following sprint.  Not only will they have to play catch up in term of understanding the requirements, they will also lose their participation in estimates and any valuable experience they have gained as an individual will not be available to the rest of the team whilst solutions are being discussed.

Why don’t we try

Sprint planning is a part of agile and that in-itself should be subject to constructive criticism. If you find your current way of planning isn’t working then discuss the problems and draw actions from them. Does the product owner or scrum master need to attend the entirety of the session? Can the session be split up into parts? Maybe the PO and BA can spend the first hour discussing the user stories so that the scrum team can be left to work out the solutions and task breakdown.

My Resharper license just expired…renew or not to renew

It’s that time of the year again when the licenses on my third party products start lapsing and I pull out my card to renew for another year. Although having used Resharper for a long time, the line between it and Visual Studio has blurred for me. So instead I’ve decided not to renew and use VS2015 vanilla style.

Off the bat, VS 2015 suddenly became blistering fast. The start up, loading a solution and even the vanilla refactoring tools became almost instant. I don’t seem to remember having this problem when I was using VS 2013 but I have definitely felt it in VS 2015. I am rocking a SSD & i7, I can’t help but feel Resharper was slowing me down which is the opposite reason as to what I bought it for in the first place. Out of the thousands tools it does offer, I felt I was only using maybe 10 of them?

I’ve been off Resharper for a few days and I am actually enjoying the change. Two features I do miss so far is Continuous code analysis using StyleCop and Continuous Testing using dotCover. VS 2017 enterprise edition introduces Live Unit Testing which should hopefully fill this void.

I’m going to give vanilla VS2015 another week or so then I’ll try some of the open source options. I did come across this little gem as a free alternative to the paid providers: http://vsrefactoringessentials.com/

Disabling NuGet Package Restore

You’ve enabled NuGet Package Restore and want to reverse that decision? Follow the steps below for every csproj in your solution:

  • Close down the solution
  • Delete the .nuget folder on the solution level
  • Open up each csproj in a text editor
  • Find the following XML tags and delete them:
<RestorePackages>true</RestorePackages>  
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />  
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">  
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>

New Marie Curie ‘In Your Area’ Search Functionality

For the past two weeks here at Marie Curie we’ve been working on new functionality for searching for Marie Curie services across the United Kingdom. It has just today finally gone live and now we can serve our supporters with better information about the key services and events in their area.

‘In Your Area’

new_inyourarea

On launch we have included the following:

  • Fundraising Groups
  • Fundraising Offices
  • Marie Curie Shops
  • Marie Curie Hospices
  • Events we run

Results are ordered by distance from the location you have entered and can be navigate by either the result list of the result map. Clicking on a result item on one result section, highlights it’s twin in the other.

The page is also fully responsive allowing you to view the search results and map as separate views.

new_inyourarea_mobile_listnew_inyourarea_mobile_map

Click here to go to the live search

Architect – Our Website Branching Strategy @ Marie Curie Cancer Care

What we use

We use a combination of Git, EPiServer and have a fairly small team which makes the challenge of using the standard pattern of Gitflow a little more difficult. So we use a part of it to help us get an excellent balance between being responsive to post production issues and minimal branch maintenance.

Challenges

Due to EPiServer controlling it’s Dynamic Data Store via code, we have to be a little more careful when switching branches on a given environment. This is because EPiServer will hide or show properties depending on what is reflected in the latest code. This could lead to impacting someone else’s work.

We do currently experience this in the Develop environment where one developer may have a code base with a deleted or renamed property. This will cause an issue with another developer who has the original property definition. So both sets of code bases will be fighting each other to set that property on the database which results in some exception behaviour when running the website.

An old colleague James Goldswain messaged me with this:

Check out the enableModelSyncCommit=”true” setting in the Episerver.config file, it enables you to disable the auto updating of properties etc, when developing in a team, found it out the hard way 🙂

We have a limited number of environments due to resources and set up time. In an ideal world we would have a new environment spin up from either a feature or hot fix branch so QA can test in isolation from everything and everyone else.

We cannot deploy hot fix or feature branches to the QA environment because that will create blockers for other members of QA. Our QA environments require all testable features to be merged to the develop branch first before deployment.

Strategy

We adjust our branch strategy from Gitflow so we:

  • Do not block any member of the scrum team from working on any environment.
  • Make the effort to keep feature and hotfix branches as short as possible in order to avoid developer going dark
  • Sync both Master and Develop branches at the end of every sprint to ensure everything is up to date. If we are going Gitflow correctly then we shouldn’t need this. (There is an occasionally extra merge commit that moves from Master to Develop due to hotfixes)
  • Feature and hotfix branches get merged as soon as possible to minimise timeline regression.
  • QA and UAT never test on feature or hotfix branches, only Develop and Master.
  • Our team is small enough to warrant not using the release branch workflow as we rarely get any issues with unfinished work at the end of the sprint.

We have four types of branches we use. The Master and Develop branches are static. Hotfix and features branches can be created any number of times and typically have short life spans before being dumped or merged into one of the static branches.

Master branch

According to Gitflow this branch represents our production ready code. We should be able to push code from this branch into production at any time.

However due to our challenges, we also use this branch to deploy to both Staging and Production. This effectively makes it our UAT and Release environments. We push to Production at the end of every sprint and also when hot fixes are merged in.

Develop branch

This is the bucket branch for any development changes that are not post production issues and not significant enough to have their own feature branch.

The branch is also used for both the develop and QA environments. This allows for QA to test singular user stories and provide feedback during the sprint.

Hotfix/xxx branches

Bugs and issues discovered during post production are worked on hot fix branches created from Master. Completed hot fix branches are then moved into both Master and Develop. Once the work is approved we then delete the branch.

Feature/xxx branches

Significant features that can be worked on in isolation are done in their own branch. We create this off Develop. Good examples include a blog or a newsletter sign up. These branches are then worked on by the developers and then must be merged into Develop once they are ready for testing.

These branches should only exist for the length of a sprint. If it needs to exist into the next sprint then ‘commits’ on the Develop branch is merged up into the Feature branch in order to keep it up to date.

Property Injection & Action Filters in EPiServer 7 CMS

I spent a bit of time putting in some custom implementation to support Property Injection on to my Action Filters before realizing that EPiServer 7 already provides this functionality for me. Doh.

In order to take advantage all you need to do is set your DI controlled interface to the generic type property of the Injected class. This will lazily set the interface when the property is used…awesome.

public class CustomFilter : ActionFilterAttribute
{
public Injected<IService> Service { get; set; }
}

Architect – Technical Design Workflow for Creating New Fundraising Page using JustGiving API

JustGiving provides an API that allows charities to create fundraising pages from their own website. Charities benefit from this by being able to integrate this functionality into their own user journeys.

I designed a user journey workflow for a user to create a JustGiving Fundraising Page in remembrance of someone for where I currently work.

From a technical perspective I worked on this taking into consideration the capability and limitations of the JustGiving API. This is so I could empower our UX guys with the right information in order to make the user journey as efficient at possible and not to get hindered by technical limitations later on in the process.

My initial thought was I needed to create a journey that allowed the user to take a minimum amount of actions to get to the end goal of creating a fundraising page. Anything after that could be included as an enhancement or additional requirements from the business that hold value else where.


This what I took into consideration is:

  • You require an active Just Giving account to create a fundraising page. The workflow supports users who do and do not have a pre-existing account.
  • At this point (as standard with any account functionality) the workflow it forks out and forks back in again ending up with the user that is logged in with an account.
  • We then describe the required fields we must expose and the optionals ones that we could take advantage of.
  • Each relevant step also mentions the correct API call that is needed.

Architect - Design Workflow for Creating New Fundraising Page using JustGiving API