Story Points are nebulous units of measure. They are not tied to a specific units such as Hours, Man-Hours, Days, or Sprints. Story Points should compare the relative complexity of one Task/Product Backlog Item (PBI) to another.

Story Points will help quantify the amount of work. Again, Story Points quantify work.

If your team is just getting started with Story Point estimation, it’s important to talk about the RELATIVITY of one task to another. You’ll want to start by coming up with a baseline. A baseline is simply picking a task and assigning it a value.

It’s been my experience to use Days to help establish a baseline with the team. So, choose a few Tasks or PBI’s and use estimates tied to days and then quickly break from the idea of days and continue estimating based on the idea of, ‘is this next task easier, more difficult, or about the same as the existing tasks that have estimates’. Since you’ve kicked off the estimation session with days, it’s easy for the team to fall back into thinking about the estimates in comparison with days, but you need to break that line of thinking. Continue estimating newly refined Backlog Items using the relative technique.

If you need to create a burn-down or release plan, start with a reasonable estimate to how many Story Points the team can complete in one sprint. This is called the Velocity – the average number of points completed per Sprint.

If you’re looking for a tool to help the team with estimation, check out http://estimated.mobi which is available for iPhone, Android Phones/Tablets, and on the Web.

There is often a little bit of awkwardness as the team prepares to start the daily standup, who should kick it off? Does the Scrum Master just point to someone? Does someone start it organically? Here’s a technique to try with your teams to streamline the start of your stand-ups.

You may have heard of FIFO – First in First Out, as used in Queue, Inventory Management, etc. However, you may not have heard of LIFS or Last In First to Start.

In your next stand-up, try a LIFS approach to who kicks-off the stand-up rotation. As the team funnels in for the stand-up, the last member to join the meeting, or the call, is the first to start. Then continue to rotate to each team member in a clockwise fashion. Try this approach today! Let me know what success you have had with your teams and this approach by leaving a comment below.

In a rut with your stand-ups? Try another twist on stand-ups, the ‘Walk the Board‘ technique.

The Daily Stand-Up is an opportunity in an Agile/Scrum project to inspect and adapt. It gives the team a chance to look at what happened yesterday, what’s the plan for today, and voice any impediments in the way. It’s a time-boxed event, not to exceed 15 minutes but it can definitely end shorter.

The typical stand-up is a round-table discussion where everyone on the team hits on those three points: yesterday, today, impediments.

While this may seem like a great flow, and it is, it gets monotonous and often fails to address other concerns on the team if bad habits form.

So, here’s a twist that you can try with your teams today.

Walk the Board

If you’re half-way, or more, through a sprint, try the Walk the Board technique. The Walk the Board technique involves bringing up the Sprint Task Board and walking the PBI’s on the board. This will call out what tasks are in progress, how anyone can help contribute to them, and when they plan on having them done. It may also allow the team to discuss which tasks they plan on picking up next. After you finish walking the board, still ask the question if anyone has any other comments or impediments.

Looking for a new retrospective technique to try with the team this sprint?

There’s a common Agile retrospective pattern called the 4 L’s, which was made popular by ebg consulting. If you want to read the original version, check out this link 4 L’s

The original technique focuses on four words starting with the letter L, hence the 4 L’s. You’ll need sticky notes, a white board, and some dry erase markers. Write the categories on the board, describe them, and provide an example of something that might fit into that category. Give the team 10-15 minutes to come up with their own topics that fit within those categories and then put them up together. The Scrum Master (SM) should then read the topics within the categories one at a time and spur up conversation. The SM should record any action items on the board as the group discusses.

4L’s Retrospective

We liked it when a good thing took on a life of its own.

We learned that it really resonated with many folks.

We lacked sharing the full understanding of the technique.

We longed for more sharing.

Before running this retrospective with my team I took a step back and tried to come up with personal examples for the 4 L’s. I could easily identify with the first three L’s, but I was confused when comparing the difference between lacked and longed for. So I decided I would come up with my own fourth L. After some thought I came up with two new categories, both starting with the letter L, and hence force this retrospective technique will be known as the 5L’s.

5L’s Retrospective

Something you liked about the sprint, team, project, etc.

Something you personally learned

Something the sprint, team, project, etc. lacked

Something considered a liability, such as risks, tech debt, etc.

Praise, shout-outs, or also known as lauded

Try out this new technique with your team for your upcoming retrospective and let me know what you think. I always enjoy positive and constructive feedback.

For those of you that wish to reference your local MSSQL database by any other name than LOCALHOST or MSSQLSERVER (which it’s named by default if you didn’t change it during the installer), you can follow the instructions below to change the name.

Note that this also works with SQL Express installations if you want to have localhost work as the alias for localhost\sqlexpress.

Alias for SQL Configuration

Launch the Sql Server Configuration Manager application, simply start typing from the windows start screen and you should see this executable utility filter to the top.

Click on the SQL Native Client XX.0 Configuration (XXbit) element in the tree, and then click on Aliases

Right-click and select New Alias

In the Alias Name field, choose a new name that you want to reference the server by, ex. localhost

In the Server field, specify the name of the server that you wish to point to, ex. localhost\sqlexpress

The Fibonacci sequence and the Mountain Goat modified sequence for Planning Poker (1, 2, 3, 5, 8, 13, 20, 40) are great intervals for Story Point estimation. It’s a great interval for determining the relativity of one backlog item (or user story) to another backlog item. However, these two intervals are cumbersome when it comes to estimating the time it takes to complete tasks associated with a backlog item.

So, the next time you are in your Sprint Planning meeting and you have already planned out the WHAT and you’re ready for the HOW, try T-shirt sizing for task estimates.

Remember that the Sprint Planning meeting can be broken into two sections. The WHAT and the HOW.

The first section of Sprint Planning, the WHAT, is what Backlog Items are we planning to bring into the Sprint. This involves the whole Scrum team, including the Product Owner. Second, the HOW is creating the tasks required to fully complete (per your Definition of Done) each Backlog Item. When you have finished tasking all Backlog Items, look back at the Sprint Backlog and commit/forecast the Backlog Items you plan to complete for this Sprint.

While your estimates for the Backlog should be relatively measured against each other with Story Points, estimates for tasks can be loosely relative and based on the hours it will take to complete the task. If you play Planning Poker with the intervals mentioned above, you may have unnecessary arguments on close estimates. Try this new approach…

T-shirt for Tasks

SM – Small – 2 hours worth of work

MD – Medium – 4 hours worth of work (1/2 day)

LG – Large – 8 hours worth of work (full day)

XL – Extra Large – too large to complete in one day, break into smaller tasks!

In the Estimated app, you can change the table’s card format. If you’re in the real-world and you don’t want to download an amazing App, AND you don’t want to use the Estimated Mobile Offline Version, you could create the cards manually.

Good luck and happy estimating! Let me know if you have tried this technique and found success, comment below!

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Action Item

In your next retrospective, look at these twelve and ask the team how they are applying, or lack their of, these principles. A healthy conversation covering these can lead to action items for your next sprint. Reply with comments below and let me know which principle your teams are struggling with.

All this, AGILE, would not be possible without the seventeen engineers that took lead to create the Agile Mainfesto. Thank you.

Past, Present, Future

Begin the retrospective by telling the tale of how the real story of Christmas Past, Present and Future goes. If you need a little reminder, check out the muppets classic video for ‘research’ or simply breeze over the Wiki Page. Next, give everyone a set of cards/post it notes and pens.

First, Christmas Past, this is an opportunity for the individual team member to reflect on things they regret or wished they could have changed. This doesn’t necessarily need to only reflect on the previous sprint, but it could reflect on the project from inception. Have the team members keep their answers to themselves.

Second, Christmas Present, this is where the team members can share in the efforts and appreciation of the team around them. Highlight collaboration, communication, teamwork and other positive comments. Again, have the team members keep their answers to themselves for now.

Third, Christmas Future, is a chance to prepare a wish list for how you wish the team/project will change/improve in the new sprints to come.

After discussing each of the sections, give the team about [15 minutes|time box] to reflect individually and write down 0..* responses to the areas. Write the categories on the board so the team can post their cards next to the words ‘Christmas Past’, ‘Christmas Present’, and ‘Christmas Future’, when the time comes.

When everyone is ready, start up again by telling them that while you appreciate them crafting regrets – it’s time to let them go! Have them hold up the regret cards and then tear/crumple them up and throw them away. Next, have the team bring their cards up and post them next to the categories. Work through the Christmas Present cards by reading the card out loud and spurring a conversation on the summary. Write down any action items. Next, do the same thing with the Christmas Future cards. There will probably be a few more action items in the Wish List.

Note that this retrospective is especially suited for sharing candy canes during the activity.

Grinch = Risks

To add a special twist on this Retrospective, try adding a fourth category called ‘the Grinch’ and discuss how the Grinch may steal christmas, which could be a metaphor for any risks that you have in the project or risks that could be upcoming. During the review of this category, there may be action items that can help to reduce or mitigate the risks.

Resharper is a great extension to Visual Studio that offers an array of complimentary features to Visual Studio’s built-in base features. Once you start using some of Resharper’s intellisense, code navigation, file navigation, testing tools, and more you’ll wonder how you even lived in the IDE before then.

One of the features that is available in Resharper is the ability to run not just .NET Unit Tests, but also other framework tests such as JavaScript unit tests. The results from any project tests are combined and made available within the Resharper Test Window. By default, JavaScript tests need a web browser to run the JavaScript engine to execute the tests. When you invoke Jasmine or qUnit tests from Resharper it will open up your default web browser, run the tests, and return the results to the Test Window. Every time you run the test it will open up your default web browser and if already open it will open up a new tab.

You can have Resharper fully contained and run the tests from within Visual Studio without the need to open a new tab or web browser. Start by downloading PhantomJS, which is kinda like a command line executable that has a built in web browser that can ‘see’ a webpage and the scripts within the page without having to open up a real browser. It’s based on the same infrastructure as Safari and Chrome (WebKit), so you can expect that it should have reasonable standards when it comes to verifying the tests. I’ll typically save utilities like this into a local folder close to the root of the main drive, ex. c:/utilities/phantomjs.

Now that PhantomJS is downloaded and you can reference it locally, next go into Visual Studio and go into the Resharper settings for JavaScript tests (Resharper -> Options -> Tools -> JavaScript Tests). Here’s a screenshot of what it should look like when you have it setup. Simply save the settings and close and now your tests should run smoothly in Visual Studio.

So you’ve seen some of the new fonts that you can use for Free from Google’s Font library and now you want to drop them into your WordPress Blog. You could probably stumble through some of the WordPress configuration options within the admin areas to eventually find an ‘Editor’ tab which allows you to edit the PHP code files for the site. You could find a file that looks like it should accept the <link> code from Google and paste it in there… but if your template ever updates you’ll lose that setting. Below is an example of what the <link> code looks like.

Like most WordPress tasks, the easiest approach is to simply navigate into the plugins area and find a plugin. For Google Fonts there are quite a few plugins, but we’ll use one named ‘WP Google Fonts‘. This plugin has by far the most support and latest updates. To use the WP Google Fonts plugin, start by finding it, installing it, and activating it. Then you can click on the settings for the plugin to see it has several slots for finding the Google Font, specifying which parts of the HTML you want to override, H1, H2, etc. or even some custom elements with your own CSS.

Posts navigation

About David…

David is passionate about software development, Agile, Julianna, and the outdoors. When he''s not scrummin, you''ll find him tinkering with the latest buzzwords and building the next billion dollar idea.