Skip to main content

Scrum Glossary – INVEST

How do we know if a Product Backlog Item is of a good quality? We need to make sure it’s not too large to be implemented in a Sprint and that it can be tested in order to say that it’s Done.

To help us ensure a PBI is of good quality, we can use INVEST:

Independant – the PBI should be self-contained and not depend on other PBIs.

Negotiable – the PBI is not an explicit contract and should be open for discussion.

Valuable – it must deliver some form of value to the business

Estimable – the development team must be able to estimate how much effort it will take to implement the PBI.

Small – the PBI must fit within a Sprint.

Testable – we must be able to define tests/acceptance criteria for the PBI so that we know when it is Done.

Scrum Glossary – acceptance criteria

Acceptance criteria are used to define when a task is completed. They allow you to meet the Testable aspect of user stories when using INVEST.
They can cover both functional and non-functional criteria.

 

Example Acceptance Criteria

If we take the following as our user story:

As a registered user, I want to book onto a training course of my choice.

 

Some possible acceptance criteria could be:

  • Send confirmation email to user when booking is saved
  • Display correctly on PC, tablet and mobile phone.
  • The form cannot be submitted without entering all required data.

Acceptance criteria are specific to a user story, while the Definition of Done covers all stories.

Scrum Events – The Sprint

Events in Scrum are used to create consistency and reduce the need for additional meetings that aren’t part of Scrum.
All events are time-boxed, so they have a maximum duration – the length of the time-box depends on the length of your Sprint.

The Sprint is essentially a container for all the other meetings and the development work. The other meetings provide opportunities to inspect and adapt the process.

 

 

Scrum process diagram

The Sprint

With a maximum time-box of one month, the Sprint is where the development work is completed, with the result being a “potentially shippable software increment”.

Potentially shippable means that the Product Owner may decide that the software can be released to the customer.
However, it doesn’t have to be released.

An increment is a small slice of software functionality, that can be added on to all the previously released increments.

But how do we know if the software is in a shippable state? That’s where “Done” comes in.

Scrum team members should have a shared understanding of what “Done” is, and this should also be shared between teams.

“Done” signifies when a Product Backlog item is complete.

 

Example Definition of Done

Each team will have its own definition, but here’s some examples of what you might include:

  • Code builds without errors
  • Code peer reviewed
  • Unit tests pass
  • User acceptance testing passed
  • Approved by Product Owner

As the Scrum Team progresses, it’s likely that the definition will become more strict.

 

The Sprint contains the Sprint Planning meeting, daily Scrums, development work, the Sprint Review and the Sprint Retrospective. There’s also the unofficial Backlog Refinement meeting which isn’t part of the Scrum Guide, but many teams find it useful to conduct.

No changes should be made during the Sprint that might endanger the Sprint Goal.

Sprint Goal

  • A high level objective for the Sprint that is met by implementing the Product Backlog Items.
  • The Team commits to the Sprint Goal rather than the PBIs.
  • The Sprint Goal provides guidance on why the Team are doing the work and allows flexibility around how the solution is achieved.

Also, quality goals should not decrease, although the scope of the sprint can be clarified and altered following discussion between the Product Owner and the Development Team.

Sprints last for a maximum of one month, but you may find it useful to use a shorter time-box. Shorter Sprints allow the team to more readily adapt to changing requirements, but make sure the Development Team has enough time to create software of value.

Shorter Sprints also reduce the risk if a Sprint is cancelled – the team has only ‘wasted’ the time in that Sprint and not any more. Additionally, they allow for more frequent inspection and adaptation, enabling the team to see more consistent progress towards a goal.

 

Cancelling a Sprint

Only the Product Owner has the authority to cancel a Sprint, but they can be influenced by stakeholders or the Development Team.
Cancellation usually occurs when the Sprint Goal becomes obsolete e.g. the feature is no longer required.

If the work that has been completed is in a shippable state, then the Product Owner can accept it. The rest of the work is put back into the Product Backlog.

 

A Sprint ends when the time-box expires and the following Sprint starts immediately (In practice this is usually the next working day).

What are the Roles in Scrum?

Scrum teams consist of a Product Owner, Scrum Master and the Development Team. Scrum teams are self-organising and cross functional.

Self-organising means that the team itself decides how to best complete the work, rather than being told by someone outside of the team.

Cross functional means the team has all the skills required to complete the work.

 

product ownerProduct Owner

The Product Owner (PO) is responsible for maximising the Return on Investment of the product development and this is usually done through the prioritisation of the Product Backlog Items.

The PO is the business contact for the team – they will liaise with stakeholders within the business to determine their desires for the product. However, only the PO can decide on the priority of these items.

The PO must also ensure that Product Backlog Items are clearly understood by the Development Team and has the final say on requirements decisions.

 

development teamDevelopment Team

The Development Team does the work to build a potentially shippable product increment every Sprint. They are self-organising, so only the team themselves decide how to create the increment.

They are also cross-functional so that the team has all the required skills to complete the work.

All members have the same title of Developer, so although members may have specialised skills, the team as a whole are responsible for all of the work.

Development Teams should have 3-9 members. Less than 3 makes it difficult to complete enough work within a Sprint, while more than 9 increases complexity.

 

scrum masterScrum Master

The Scrum Master is a servant-leader for the Scrum Team. They have a variety of responsibilities, which can be seen in full in the Scrum Guide, but the most important of these are:

  • They facilitate the work of the team by ensuring Scrum practices are understood and followed.
  • Protect the team from distractions such as stakeholders trying to sneakily get their feature worked on first.
  • Remove impediments.
  • Enforce time boxes.

The Scrum Master is not a Project Manager. A Project Manager runs the project and team, and is accountable to the business for completing that project. They may set work for team members, prioritise features and manage risk.
A Scrum Masters’ role is to facilititate the process and the team. Their accountability is to the Scrum process.

Scrum Glossary: Scrum

What is Scrum?

Simply put, Scrum is an Agile framework for developing complex products.

While it is often used for developing software, it can be used for any complex products, especially where requirements are not known or may change frequently.

Right at the start of a project we know less than we’ll ever know about the requirements. Scrum accepts this and doesn’t try to define all the requirements up front – like you would do in the Waterfall method. Instead, Scrum uses an empirical approach of Transparency, Inspection and Adaptation.

  • Transparency – the people involved in the Scrum process should be able to easily see the state of the process and the artifacts involved.
  • Inspection – looking at the process to determine what went well and what could be improved.
  • Adaptation – based on the results of Inspection, we make changes so that the Scrum process runs more smoothly next time. This way we are constantly and iteratively improving the process.

So requirements are discovered and refined as the project progresses.

Scrum aims to regularly release potentially shippable software increments using a series of meetings, with associated roles and artifacts.

We’ll look at these in more detail in subsequent posts, but the basic process is as follows:

 

Scrum process diagram

 

  1. The Product Owner creates a prioritised list of product features they’d like. This is called the Product Backlog.
  2. At the Sprint Planning meeting, the team takes a selection of these features from the top of the list to create the Sprint Backlog.
  3. These features are what they think can be completed during a Sprint – a 2-4 week period of development.
  4. The Development Team works to create the product increment.
  5. The team meets daily at the daily Scrum, where they report on progress.
  6. The Scrum Master helps to coach the team in the whole process, while removing impediments that they may encounter.
  7. At the end of the Sprint, the work we have completed so far should be potentially shippable I.e. Released to customers.
  8. Following this, the Sprint Review meeting allows the Stakeholders to view what was completed during the Sprint and for the team to discuss any issues they had. It also enables the Product Backlog to discussed.
  9. The Sprint Retrospective meeting allows the team to Inspect the Sprint to identify any issues and what can be improved.
  10. Backlog Refinement isn’t an ‘official’ Scrum meeting, but many teams find it useful. It ensures the Product Backlog accurately reflects the Product Owners needs by removing, creating and prioritising User Stories.

Choosing new Web Hosting

Godaddy

I had hosted my website with GoDaddy since 2007 and had been fairly happy with them. However, last year I noticed that a large number of files had disappeared from my hosting without explanation, resulting in my website being broken.

Off I went, to contact GoDaddy support, only to discover that they had now discontinued their online help and that you had to phone them up. A web host with no online support?!

I tried their support Twitter, but they were extremely limited in what they could do. Only telling me that they were “working on it” and couldn’t tell me how long until the issue would be resolved.
Luckily I had my own backups so I was able to restore the most important files.

Even since this incident, I have noticed the modified dates of large numbers of files are not what they should be, indicating they’ve been restored from backup without my knowledge. Who knows how many times this has occurred without me noticing.

The final straw was when I wanted to upgrade the version of PHP on my Windows hosting. It was restricted to version 5.3 which went unsupported in 2014!

PHP 5.3 support discontinued

Don’t even get me started on all the spam emails they send you…

 

Searching for new web hosting

So my GoDaddy hosting was up for renewal and I decided to switch hosts. The resulting search was far more difficult than it should have been.

Usually you can search for a particular product/company and find a good number of unbiased reviews. But with web hosting, it seems that the majority of comparison and review sites just promote those hosts who give the largest affiliate payouts.

I even tried looking on forums, but wasn’t able to find a consensus on the best web host.

I did manage to find a few review sites that seemed relatively trustworthy:

Let me know in the comments if there are any other web hosting review sites that you’d recommend.

 

SiteGround

After hours of searching, and chatting to their online support, I decided on Siteground (affiliate link!).

Siteground web hosting

My requirements included:

  • PHP 7
  • MySQL
  • A decent amount of email storage
  • Free SSL certificate (Siteground use Let’s Encrypt which they will automatically renew for you).
  • Online /email support
  • UK based data centre.
  • Not too expensive!

The admin area of Siteground is a bit nicer to use than GoDaddy and although I haven’t done any official tests, my website seems to load faster than before.

I purchased the StartUp plan which came to £39.60 for a year.

 

Conclusion

I’ll update this post if I encounter any issues with Siteground. Let me know in the comments if you’re a Siteground customer and what you think of them, or if there’s a web hosting company that you’d like to recommend.

Multiple Models in one View – ViewModels in ASP.NET MVC

Following on from my previous post on using ViewBag and TempData, this post will show you how to use ViewModels so that you can interact with multiple Models in one object and pass its properties to a View.

ViewModels are strongly typed, so they give you the following advantages over ViewBag:

  • Compile-time checking (ViewBag is dyanamically typed, so you’ll only see any issues at run time).
  • Intellisense (it’s worth using ViewModels for this functionality alone!)
  • Your Data Annotations in the ViewModel won’t be removed, like they are with Database Models when you add to/refresh the Entity diagram.

ViewModel Diagram

When we create a ViewModel, all we’re really doing is combining two Models from our database, into one ViewModel which will exist as a Class.

 

Creating a ViewModel

In Visual Studio I tend to keep my ViewModels in a ViewModels folder. But they can also be referenced from an imported DLL if required.

Continuing with the Car theme, here’s the ViewModel that we’d create:

 

Getting the data to the View, via the Controller

You create an instance of your ViewModel the same way you would create an instance of any other Model.

So we find the Car for the ID that’s been supplied. We then pass this car to another method CarToTuningCar which will convert the Car object into a TuningCarViewModel.

If you don’t have many properties to map, you can do it manually as shown below. But this can become time-consuming if you have lots of properties. In this case, you might want to try out AutoMapper.

We use the methods below to get the actual values from the Tuning table:

 

Rendering in the View

We need to ensure that the View uses our new ViewModel, so update it accordingly:

You can then access the properties of the ViewModel as usual:

 

Conclusion

ViewModels in ASP.NET allow us to work  with multiple Models and present their data in one View. Once you’ve got past the initial trickyness, you’ll find they over you advantages over using ViewBag and TempData.

Multiple Models in one View – ASP.NET MVC ViewBag and TempData

If you’re new to web development in ASP.NET or perhaps you’re moving over from Web Forms, one aspect of MVC that can be tricky to get your head around is how to combine multiple Models in one View.

By default, Visual Studio will scaffold your Views so that they can only interact with one Model.

But what if you need your Controller Action to interact with more than one Model at a time?

Probably the “easiest” method and the one that you’ll see in most of the official Microsoft tutorials, is to use ViewBag. ViewBag doesn’t have a direct equivalent in Web Forms, but it’s most closely comparable with Page.Items.

So, in your Details view, if you wanted to display data from two separate Models, you would have something like this:

Next, in your Car Details View (Details.cshtml), you would access the ViewBag to render out your turbo string:

Bear in mind that ViewBag can only be used in a Controller and then displayed in the corresponding View. If you do a redirect, you’ll lose the value stored in the ViewBag.

If you need the data to survive a redirect, use TempData instead. TempData’s equivalent in Web Forms would be a Session variable.

 

This is nothing particularly wrong with using ViewBag and TempData (although the pedants on StackExchange would say otherwise!), but there is another method called ViewModels that has some advantages. I’ll look at ViewModels in my next post.

Feel free to post any questions or comments down below.