Many people new to agile will hear of having a âSprint 0â and wonder what its goal and activities should be. Indeed many agile practitioners would say it shouldnât exist, and youâll often see comments online saying something along the line of it being a construct introduced by senior management used to cling on to waterfall ways of working.
Let me start my saying that the latter statement is a wholly unfair criticism and generalisation of senior management that has no logical basis. Why should an âold dogâ in senior management be less capable of embracing agile than a âyoung pupâ fresh out of university and eager to learn. On the contrary, the ability to recognise the need for change and adapt is a key ingredient in good senior management.
I think everyone would agree that prior to kicking off the Sprint 1 planning session, itâs helpful to have:
A high level technical architecture for what youâre building
A definition of done
Some basic epics or stories to get things rolling
Licences and tooling for the team
Environment and CI/CD processes in place
Some established ways of working that can be improved over time
The above tasks more often than not can be completed in around 1-2 weeks depending on constraints, and are ideal candidates for âSprint 0â activities. Iâve observed from experience that it is the declaration of this period as a Sprint which is the source of confusion and disagreement since these tasks do not deliver value to the customer.
My recommendation would be to run a mini Kanban style project to complete these tasks/tech stories, and youâll most likely find it coincidentally takes around an average sprint length to complete. Whether itâs called âSprint 0â, a âproject before the projectâ or âproject initiation periodâ doesnât really matter. Sure, you may offend some agile purists, but who cares! Lengthy debates on topics such as the naming of a 2 week period that occurs once in the lifetime of a project are an enormous waste of time and effort.
Keep in mind that the following are examples of items which should be avoided in this initial period:
Calculating the Number of Story Points to Accept into Initial Sprints
A common question that inevitably arises when kicking off a new agile Scrum project is âHow many stories or story points should we take into our first sprint?â Once youâve achieved a predictable enough velocity after a few sprints, and your estimates become more accurate, it is quite easy to work out roughly how many points you can take into a sprint. However, at the start of a Scrum project, the answer to this question becomes a little more tricky since you lack sufficient data to make an informed decision.
Iâve seen many misguided efforts to answer this question such as âWell a good benchmark is 50 points per personâ or âLetâs workout roughly how many hours a point is worth, and how many hours we have as a team, then go from thereâ or even âLetâs just pick anything, it doesnât matter and the first few sprints will always be way offâ. The first idea of using 50 points is of course bordering on madness. First of all, a story point has no meaning outside of a given team - 5 points to Team A means nothing to Team B. Secondly, where does an arbitrary number such as 50 come from? Where is the data to support this? The second strategy, though not as nonsensical, is also inadvisable and dangerous for future estimations. By allowing people to picture a correlation between points and hours, you are setting a dangerous precedent for future estimation sessions where people will continue to adopt this mindset. The argument âWeâll just do it this onceâ doesnât carry much weight and conjures up memories of âIâll just have one more slice of cake, and then stopâ. Furthermore, you donât know at this point how many hours a team member actually works per day. Add to this the fact that points are supposed to be about effort and not time passed, and the flaws in second strategy become even more apparent (though there are plenty more). The third line of reasoning is just accepting defeat without even trying. Iâve lost count of the number of teams who laugh at the chaos when recalling the early days of their project. Thereâs no reason you canât get it right from the start. Agile places an emphasis on high quality team members, so thereâs no good reason not to trust the estimating and experience of your team and their ability to get it right this time!
The most effective strategy for answering this question which I have seen is actually one of the most simple. In your planning session, after you have groomed, discussed and prioritised the backlog you will most likely have used planning poker to get point estimates for a reasonable number of stories towards the top of the backlog. Afterwards, simply start going through the stories in descending order and ask the question to your team âDo we think we can complete this story as well?â Forget the story points (cue cries of Heathen! and Blasphemy!). Simply look at what youâve accepted so far, and ask yourself whether in two weeks time, you realistically think you will have been able to complete already accepted stories plus this additional one. Once the someone answers no with a reasonable justification, stop. Trust your team members judgement, especially the more experienced, and let them exercise freedom of speech if they have any doubts whatsoever.
Once youâve completed your first sprint, youâll be on your way to understanding what your team is capable of accepting into a sprint. Even once you have an idea of an average velocity and can start basing sprint content based on points, itâs always valuable to take a step back and a realistic look at what youâve accepted and think whether itâs possible. Donât become a slave to story points - agile teams should be continually trying to refine and improve their ways of working and keep in mind a few key points:
1. Successful agile teams need quality team members who can draw on their past experience to inform decisions. The more experienced your team, the easier the initial sprints become.
2. Be conservative. Inevitably at the start of a project there are going to be unforeseen issues that need ironing out. Your code reviews will take longer, your CI tooling might fall over etc. which will most likely eat up more effort from senior team members
3. Do not forget the human aspect of software engineering teams. Donât set unachievable goals that will damage team morale - thereâs no better feeling than finishing a sprint and knowing that you nailed it as a team. Getting off to a good start will set the tone for future sprints
Itâs always useful to stay up to date on the best practices for your programming language of choice, however itâs also perhaps just as important to follow recommended and community-standard practices when make use of popular frameworks. Following these practices will make your code easier to understand for those familiar with your chosen framework, and often improve itâs maintainability. Here are 3 best practices weâve learnt from our experiences with Symfony.
Best Practice 1: Separate Business Logic from Your Bundles
For small projects, often everything you write will be contained within a small bundle or set of bundles. You should always try to decouple your bundles from each other and reduce hard dependencies between them. However, you should also consider moving all your domain related logic and code out of the Bundle directories and into appropriate namespaces to help decouple your code from the Symfony framework.Â
It is good practice to keep all Symfony specific code and configuration in a Bundle directory/namespace, allowing it to effectively act as the bridge between your code and the Symfony framework. That way, if you decide to get rid of Symfony and make use of another framework, you can take your code with you and add in any necessary configuration and classes to wire it up to the new framework.
A good example of this is the Doctrine Migrations bundle. The core doctrine migrations code is stored in the doctrine/migrations package, and the doctrine/doctrine-migrations-bundle integrates this package with Symfony.
Best Practice 2: Donât use Annotations
This may be considered a tad controversial however bear with me. Annotations, provided by the excellent sensio/framework-extra-bundle, are great for getting a Proof of Concept (PoC) up and running quickly. They are simple, convenient and it involves less YAML (or XML) configuration files. Itâs very easy to create some models and put all the constraints and validation logic as private property annotations. However, this introduces coupling of your models to the Symfony framework because the framework-extra-bundle is Symfony specific. If, for example, you move these models over to another project based on Laravel, the annotations become meaningless, except perhaps as some form of really bizarre documentation... Itâs better practice to keep your validation and constraints definitions in YAML configuration files as it will allow you to make use of your models in another framework, without needing to change them (in theory). Almost all good frameworks include validation components that are configured differently, and therefore this configuration is best kept in framework specific classes/configuration files.
This best practice applies to a greater extent when it comes to writing your controllers. Again, annotations in controllers can provide a powerful way of getting controllers and routing wired up in a few lines of code, however it will also lead to Controllers that will not work in a non-Symfony project. Though it is more effort in the short run, for non-trivial projects you should avoid routing annotations in favour of YAML based routing files. Furthermore, avoid using annotations such as the @ParamConverter in favour of retrieving these parameters yourself using the Request object passed to your controller methods.Â
Applying this best practice requires judgement on your part. The convenience and speed in the short run, may indeed be worth the technical debt it incurs. Itâs a judgement call that needs to be made in the context of your project.
Best Practice 3: Storing Sensitive Information
The Symfony documentation recommends as a best practice that sensitive credentials such as database credentials should be stored in environment variables and these environment variables should in turn be referenced in your parameters configuration file. Itâs important to realise here that whilst this can prevent passwords from accidentally being checked into version control, and it does provide a degree of security by obfuscation, from a security point of view, utilising environment variables is arguably no more secure than storing them in plain text your parameters configuration file with appropriate file permissions. If a determined malicious user gains access to your server that would allow him the ability to view your configuration file, theyâll probably be able to access the env of running processes.
A more secure practice would be to store encrypted credentials as environment variables, then use the encryption key to decrypt these details at runtime. The management of this encryption key can be handled by your sys admins. As an absolute minimum it should be stored with strong ACLs outside your web root. Admittedly, this solution is still not perfect, but it does add yet another layer of security, as well as protecting against accidental dumping of your details (think phpinfo!). Ultimately, if you want to store your passwords securely, you should be looking at enterprise level Hardware Security Modules.
Prepending Your Git Commit Messages with User Story IDs
Itâs always a good practice to prepend your commit messages with something meaningful. For example, it is often common when working with project management tools, such as Jira, to prepend your commits with the User Story ID that youâre are working on. Itâs also pretty standard, especially if using tools like BitBucket and creating branches from Jira, for your feature branch name to be the User Story ID plus title of the task/story. Wouldnât it be great if you could append the ID from Jira to your BitBucket commits (and get the benefits of Smart Commits) without having to constantly memorise ticket numbers, or repeatedly run git branch to check the ticket number and branch name? Fear not, Git Hooks to the rescue.
Note: All teams have different standards and practices (or at least should have!) for writing commit messages so achieving a one size fits all commit message formatter is difficult, but the code in this tutorial can be very easily adapted to match your own style.
Let's start off by looking at a basic commit message. A fairly common style is along the lines of
ABC-123 - a succinct description of work completed
where ABC-123 is the ticket/story ID in your project management platform (e.g. Jira). It's a simple format and will enable linking of commits to BitBucket with stories in Jira via Smart Commits. Our goal in this tutorial is to prepend commits with this ticket number.Â
A good practice when working with agile and feature branches is to include the ticket number in the feature branch name as it's good for traceability. If you're using Jira to create your feature branches, you can create branches from the UI of the ticket and it will automatically have the ticket number prepended to the branch name. For this tutorial, weâll assume this best practice is being followed. Therefore, if our branch was named "ABC-123-some-nice-feature", we want to extract the ABC-123 segment and either prepend or append it to our commit message. This is where Git Hooks come in. Git Hooks are simply a way to trigger custom scripts when certain Version Control System (VCS) events occur and they can be found in the .git/hooks directory of your git based project.Â
Step 1: Create the hook file
Open up the .git/hooks directory of your project and you'll see a handful of sample hook files for various VCS events. For our goal, we want to change the prepare-commit-msg.sample script which as the name suggests, is triggered when you make a git commit and prepare the commit message. Open this file with your favourite command-line text editor and delete all the commented out boilerplate code in there.Â
Step 2: Add the code to be triggered on commit
Copy and paste the following script in it's place and then rename the file to prepare-commit-msg (i.e. remove the .sample).
#!/bin/bash # Include any branches for which you wish to disable this script if [ -z "$BRANCHES_TO_SKIP" ]; then BRANCHES_TO_SKIP=(master develop test) fi # Get the current branch name and check if it is excluded BRANCH_NAME=$(git symbolic-ref --short HEAD) BRANCH_EXCLUDED=$(printf "%s\n" "${BRANCHES_TO_SKIP[@]}" | grep -c "^$BRANCH_NAME$") # Trim it down to get the parts we're interested in TRIMMED=$(echo $BRANCH_NAME | sed -e 's:^\([^-]*-[^-]*\)-.*:\1:' -e \ 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/') # If it isn't excluded, preprend the trimmed branch identifier to the given message if [ -n "$BRANCH_NAME" ] && ! [[ $BRANCH_EXCLUDED -eq 1 ]]; then sed -i.bak -e "1s/^/$TRIMMED /" $1 fi
Now simply run git init to pick up the changes and try making a commit! You should see the ticket ID from your branch automatically prepended to your commit message.
Step 3: Going Global
Manually adding this hook to all your projects is boring and not very DRY. Luckily, applying this globally is easily done by modifying your global git configuration to use a template:
Firstly, set up a git template directory. In this example weâre using the .git-templates folder weâve created in our home directory:
Done! Now whenever you run git commit, it will prepend the first segments of the branch to the commit message! For existing projects, you just need to reinit the git directory (donât worry, it wonât break anything!) by running the following in the project root directory:
Google Analytics is an essential part of any website, and should be your first port of call when looking to get some basic analytics set up on your site to begin understanding your users.Â
However, Google Analytics is an often misunderstood tool and for novices the process of getting flows set up can be a challenging one. In many cases, it is often worth hiring trained professional to help get your funnels and tracking set up correctly. In recent years there has been a wave of tools providing alternative, analytics designed to compliment other analytics tools by focusing on one particular area of analysis. This article will take a quick glance at 3 of these tools which we at Digital Turtle like to recommend to our clients.
Heap
Heap is an online analytics tool that takes almost no time to get up and running. Simply sign up, provide some basic details and itâll provide you with a piece of JavaScript to copy and paste into your site. You can then use their event visualizer tool to view your site, and point and click at any UI element on your web page, choose an interaction type, and Heap will track it. This kind of interactivity data is essential for understanding the value of new content you add to your site. Added a slider and arenât sure whether to autoplay it? Simply track how people are (or perhaps arenât) interacting with the slider!
One additional cool feature is Heapâs concept of retrospective analytics. Effectively, once you install Heap on your site it will start tracking everything, so that if you happen to forget to tag a button for example and realise a few days later, you can simply create the tag in Heap and it will provide retrospective data. Heap also provides all the standard analytics suite tools youâd expect such as customised queries, graphical visualisation and funnel creation.
The beauty of heap is itâs simplicity in getting started, however with coding and SQL knowledge, it is possible to take it to the next level and conduct extremely powerful analysis of your UI elements.
HotJar
HotJar describes itself as an âAll in One Analytics & Feedbackâ tool, and to be fair, it is packed full of useful features. However, the 2 big features that make HotJar standout are itâs session recording functionality, and form analysis tools.Â
Watching playback videos of your how your customers journey through your site can be invaluable in improving and refining the UX of your site. Heatmaps (which HotJar also provides) are useful, but by actually watching full playback of a customer journey, you can gain insights into which content is capturing interest and which areas of the site are confusing. It becomes far easier to realise if customers are attempting to use a section of the site but are having difficulty knowing where to click, or for spotting if something simply isnât working correctly and what the resulting exit flow looks like.Â
We all know data capture is hard but forms are a huge part of most websites, and indeed represent a key conversion point on most sites. Whether itâs contact forms, checkout forms, or even feedback forms, theyâre often a pain point for users, and if done poorly can be a real conversion killer. Tools such as Typeform are trying to rethink forms, but data capture as we know it will remain a part of the online experience for the foreseeable future. HotJar recognises this an provides comparative, field level form analytics to help you refine and craft the optimal form that will maximise conversions.
In terms of installation, there are many plugins and guides for a large number of CMS solutions/SaaS solutions like Shopify, Wordpress and PrestaShop. The free tier is pretty generous and will definitely be more than enough for you to decide if you feel HotJar can add value to your UI decision making process.
A downside for HotJar is that at the time of writing this article, it does not have full support for Single Page Application (SPA) frameworks/libraries such as ReactJS and AngularJS (our two favourites right now). It is in their roadmap and a feature that many users are eagerly awaiting. If this is a real sticking point for you, then you can also take a look at Inspectlet which is a similar service to HotJar that has support for SPAs.
Optimizely
Optimizely is one of the biggest players in the A/B testing space and with good reason too. They have a robust, proven A/B testing platform that allows you to easily define different âexperiencesâ for every step of your customer journey, and to gather statistical data about those visualisations to see how each experience is performing. With Optimizely, discovering statistically significant patterns when comparing layouts on any device becomes much easier thanks to their Stats Engine.
The Optimizely Stats Engine is a powerful tool that encourages the development of a true understanding of the statistics your tools are reporting, with a specific focus on statistical significance. Taking A/B testing results at face value and making decisions about your site can be potentially misleading in terms of searching for ways to improve your conversion rate, and even have adverse affects. The Optimizely Stats Engine lets you easily analyse and compare layouts based on multiple goals and criteria to help ensure that your deductions from your stats are significant.Â
Optimizely also offer Personalisation tools which is beyond the scope of this article, but worth checking out!
Closing Thoughts...
Behavioural analytics is tough, thereâs no questioning that. There are many different approaches to working out which design provides the best UX and conversion rate. Itâs always important to consider that a simple sales comparison that results in Layout A > Layout B may be misleading if the results are not statistically significant. The good news is that the analytics space is thriving right now and there are a huge number of tools, like those mentioned in this article, to help you gather insights into how your customers are interacting with your site.Â
Digital Turtle are experts in formulating and implementing analytics strategies, Get in touch to see how we can help you and your business better understand your customers.
