Scrum-and-XP-from-the-Trenches#04: Sprint Demo & Retrospective

Last session we covered the following:

  • PART FIVE – How we Communicate Sprints
  • PART SIX – How we do Sprint Backlogs
  • PART SEVEN – How we Arrange the Team Room
  • PART EIGHT – How we Do Daily Scrums

You can check it from here Scrum-and-XP-from-the-Trenches Session#03: Sprint Backlog & Daily Scrum.

In this session we will cover the following:

PART NINE – How we do Sprint Demo

  • The Sprint Demo (Sprint Review)
  • Why we insist that all sprints end with a demo(Review)
  • Checklist for Sprint Review
  • Public vs. Internal Sprint Review
  • Dealing with indemonstrable stuff

PART TEN – How we do Sprint Retrospectives

  • Why we insist that all teams do retrospectives
  • How we organize retrospectives
  • What can we do better next sprint?
  • Spreading lessons learned between teams
  • To change or not to change
  • Examples of things that may come up during retrospectives

PART ELEVEN – Slack Time Between Sprints

  • Slack Time Importance
  • Slack Time Examples
  • Lab Days


Next session isA, we will cover the following:

  • PART TWELVE – How we do Release Planning and Fixed-Price Contracts
  • PART THIRTEEN – How we combine Scrum with XP

Thank You, and always keep it simple & straightforward 🙂



Scrum-and-XP-from-the-Trenches Session#03: Sprint Backlog & Daily Scrum

Last session we covered Part 3: How we prepare for sprint planning and Part 4: How we do sprint planning. You can check the previous session from the following links:

Scrum-and-XP-from-the-Trenches Session#01: Intro & Backlog

Scrum-and-XP-from-the-Trenches Session#02: Sprint Planning

In our 3rd session we will cover the following:

PART FIVE – How we Communicate Sprints

  • Sprint Info Page

PART SIX – How we do Sprint Backlogs

  • Wall-based Task Boards
  • How the Task Board works
  • How the Burn-Down Chart works
  • Task-board Warning Signs
  • Hey, What about Traceability?!
  • Estimating Days vs. Hours

PART SEVEN – How we Arrange the Team Room

  • The Design Corner
  • Seat the Team Together!
  • Keep the Product Owner at Bay
  • Keep the Managers and Coaches at Bay

PART EIGHT – How we Do Daily Scrums

  • Stand Up Meeting (Daily Scrum)
  • How we Update the Task Board
  • Dealing with Latecomers
  • Dealing with “I don’t know what to do today”

Next session isA, we will cover the following:

  • PART NINE – How we do sprint demos
  • PART TEN – How we do sprint retrospectives
  • PART ELEVEN – Slack time between sprints

Thank you and Keep it simple & straightforward! 🙂

Scrum-and-XP-from-the-Trenches Session#02: Sprint Planning

In the last session, we covered part 1 and 2 from the book. We talked about the basic requirements for Scrum and how to make the product backlog. You can check it from the following link:

Scrum-and-XP-from-the-Trenches Session#01: Intro & Backlog

In the 2nd session, we will cover the following:

PART THREE – How we prepare for sprint planning

PART FOUR – How we do sprint planning

  • Sprint Planning Meeting Purpose.
  • Sprint Planning Meeting Concrete Output.
  • Why the product owner has to attend?
  • Why quality is not negotiable?
  • Sprint-planning-meeting agenda.
  • Defining the sprint length and goal.
  • Deciding which stories to include in the sprint.
  • How can product owner affect which stories make it to the sprint?
  • How does the team decide which stories to include in the sprint?
  • Why we use Index Cards?
  • Definition of “Done”
  • Time estimating using Planning Poker
  • Clarifying Stories
  • Breaking down Stories into Smaller Stories
  • Breaking down Stories into Tasks
  • Defining Time and Place for the Daily Scrum
  • Tech Stories
  • Bug Tracking System vs. Product Backlog
  • Sprint Planning Meeting is Finally Over!

Next session covers the following:

  • PART FIVE – How we Communicate Sprints
  • PART SIX – How we do Sprint Backlogs
  • PART SEVEN – How we Arrange the Team Room
  • PART EIGHT – How we Do Daily Scrums

Scrum-and-XP-from-the-Trenches Session#03: Sprint Backlog & Daily Scrum

Thanks and Keep it simple & straightforward 🙂

Scrum-and-XP-from-the-Trenches Session#01: Intro & Backlog

Within our knowledge transfer activities that held up in the team, I’ve been asked to prepare a session about Scrum so that the whole team can get familiar with Scrum and be able to apply it.

I decided to talk about Scrum via a book called Scrum-and-XP-from-the-Trenches by Henrik Kniberg. It’s a free book and you can download it from here.

This book includes:

  • Practical tips and tricks for most Scrum and XP practices
  • Typical pitfalls and how they were addressed
  • Diagrams and photos illustrating day-to-day work
  • Testing and test-driven development
  • Scaling and coordinating multiple teams
  • Dealing with resistance from inside and outside the team
  • Planning and time estimation techniques

We already had 8 sessions that cover this book from start to end. I told myself why not make those sessions public and share them with you hoping that it may help you to start applying Scrum in your team.

In our first session we will cover the following:

  • Basic requirements for Agile iterative development
  • Teams need to know Scrum basics
  • The Nokia standards for Scrum
  • Focus on Getting Things Done
  • PART ONE – Intro
    • What is Scrum?
  • PART TWO – How we do product backlogs
    • Stories Main Fields
    • Additional Story Fields
  • How we keep the product backlog at a business level

Next session covers the following:

  • PART THREE – How we prepare for sprint planning
  • PART FOUR – How we do sprint planning

Scrum-and-XP-from-the-Trenches Session#02: Sprint Planning

Thanks and always keep it simple & straightforward 🙂


If you haven’t heard of OAuth or OpenID, you have most certainly used it in day to day life. Have you provided your google username/password and logged in to StackOverflow or used your account to post comments on someone’s blog or used third party Twitter clients whom you have given permission to use your Twitter account or used Facebook to post comments on some tech blog site? If answer to any of the above is a yes, you have seen OAuth or OpenID in action.


The diagram above demonstrates the Authentication process for an OAuth provider.

The overall workflow is as follows:

  1. Application (Relying Party) registers with OAuth provider and obtains an Application specific key (secret). This is a one-time process done offline (not shown in above image).
  2. Next the Application (Relying Party) has to pass the Application key to the provider every time it intends to authenticate someone.
  3. User of the Relying Party needs to be registered with the Provider (again a one-time offline process)
  4. Every authentication request directs the user to the Auth Provider’s site. The user enters the Username and Password that they obtained in Step 3 above. The Provider verifies the account credentials, then it matches the Application Key and provides a token back to the Relying Party with which only the Authorized actions can be performed.

Today we will learn how to use ASP.NET’s integration of the DotNetOpenAuth library that allows you to integrate using Twitter/Facebook/Google Id and other similar pro viders.

Getting Started – Registering an Application with Twitter

Step 1, registering our application with Twitter.

1. Navigate to and click on the Sign In (top right)

2. Log in using your Twitter credentials. Hover over your Account Info and Click on ‘My Applications’

my applications

This will take you to the Applications page where you can register a new Twitter Application. This is going to be the Relying Party.

3. Next click on ‘Create a new application’ and navigate to the new application page.

It asks for the following details

  • Provide proper Name and Description these will come up every time a new user Authenticates at your site.
  • Specify a callback URL that would point to a site address. You can point it to
  • Notice the Website is setup as localhost address. This is for testing purposes. Once you have the application going
    set it back to the actual website.
  • Scroll down, read the Developer Rules of Road carefully and click on Yes, I agree.
  • Fill in the captcha and click on ‘Create your Twitter Application’.

4. Twitter will navigate to a page similar to the following:

demo app

Next click on the ‘Create my access token’ to generate the access token that our app will be using along with the Consumer Key and Consumer secret. Remember all three values shouldn’t be shared.

Using Registration information to Authenticate with Twitter

1. Create a new ASP.NET MVC Web Application and select the Internet Template.

2. Open the AuthConfig.cs from the App_Start folder and uncomment the code to register the Twitter Client

public static void RegisterAuth()
                                  consumerKey: “”,
                                  consumerSecret: “”);

3. Put the keys in web.config and update the above code to get the values from ConfigurationSettings.

4. Update the project’s properties to run the application on the same port as specified in the URL above http://localhost:8765/

5. That’s pretty much it. Run the Application and click on the Log On Link to be presented with the new Login page

As you can see we have a button to log in to Twitter. Let see what happens when we click on it.

6. On clicking twitter the application gets routed to a Twitter page


Note: This is why when using OAuth you have to be careful to request for only as much information as you need. If your app seems terribly nosy, the end user may choose not to give you permissions.

– On successful authentication, you will see a brief flash of ‘redirection in progress’ message and the user will be sent back to our application again.

7. For the first time log in, we will be requested to register you user name.

8. Once you Register, you are logged in as an Authenticated user for the application


With this we have completed Step 2, 3 and 4 of the OAuth process.

Thank you & Keep It Simple and Straightforward 🙂


MVC 4.0: Ajax Search with JSON and Client-Side Templates

I talked before about Ajax search but it was using Helper Methods, here we will see how to implement Ajax Search using JSON and Client-Side Templates.

Mustache Client-Side Template

The following code is an example using Mustache, a template library we will use in this post:

<span class="detail">
     Rating: {{AverageReview}}
     Total Reviews: {{TotalReviews}}

This template would work against an object with AverageReview and TotalReviews properties.
When rendering templates with Mustache, the templates place the values for those properties in their proper location. You can also render templates against an array of data. More documentation for Mustache is available at

To begin writing templates, you can include a script reference to Mustache in the layout view:

<script type="text/javascript" src="~/Scripts/mustache.js"></script>

Now this is where templates come into play. A template is markup embedded inside a script tag. The following code shows a template, as well as the search result markup where the results should display:

<script id="artistTemplate" type="text/html">


<div id="searchresults"></div>

Notice that the script tag is of type text/html.

Modifying the Search Form

We will not use Ajax.BeginForm helper method instead we will write it from scratch.

<form id="artistSearch" method="get" action="@Url.Action("ArtistSearch", "Home")">
    <input type="text" name="q" data-autocomplete-source="@Url.Action("QuickSearch", "Home")" />
    <input type="submit" value="search" />
    <img id="ajax-loader" src="~/Content/Images/ajax-loader.gif" style="display:none"/>

Without the helper you’ll also need to write your own JavaScript code to request the search result from the server. You’ll place the following code inside your view or place it in outside script file:

$("#artistSearch").submit(function (event) {
    var form = $(this);
        url: form.attr("action"),
        data: form.serialize(),
        beforeSend: function () {
        complete: function () {
        error: searchFailed,
        success: function (data) {
            var html = Mustache.to_html($("#artistTemplate").html(),
            { artists: data });

The to_html method of Mustache combines the template with the JSON data to produce markup. The code takes the template output and places the output in the search results element.

Thank you,
Keep It Simple and Straightforward 🙂

MVC 4.0: Autocomplete with jQuery UI


Autocomplete is a very nice feature that makes your website more responsive to user inputs. I like this feature very much 🙂

Before you use autocomplete, you can set up the application to include the base theme style sheet by adding it to the layout view:

<link href="~/Content/themes/base/jquery-ui.css" rel="stylesheet" type="text/css" />

You’ll need to fi nd the input element from JavaScript and attach the jQuery autocomplete behavior. One approach to do this is to borrow an idea from the MVC framework and use a data dash attribute:

<input type="text" name="q" data-autocomplete-source="@Url.Action("QuickSearch", "Home")" />

Note that you’ve pointed the source to a controller action.

You can use the following code during the ready event to attach autocomplete to all inputs with the data-autocomplete-source attribute:

$("input[data-autocomplete-source]").each(function () {
var target = $(this);
target.autocomplete({ source: target.attr("data-autocomplete-source") });

Autocomplete expects to call a data source and receive a collection of objects it can use to build a list for the user. The QuickSearch action of the HomeController needs to return data in a format autocomplete will understand.

Autocomplete expects to call a data source and receive objects in JSON format. Fortunately, it’s easy to generate JSON from an MVC controller action, as you’ll see soon. The objects must have a property called label, or a property called value, or both a label and a value. Autocomplete uses the label property in the text it shows the user. When the user selects an item from the autocomplete list, the widget will place the value of the selected item into the associated input. If you don’t provide a label, or don’t provide a value, autocomplete will use whichever property is available as both the value and the label.

To return the proper JSON, you’ll implement QuickSearch with the following code:

public ActionResult QuickSearch(string term)
var artists = GetArtists(term).Select(a => new {value = a.Name});
return Json(artists, JsonRequestBehavior.AllowGet);
private List<Artist> GetArtists(string searchString)
return storeDB.Artists
.Where(a => a.Name.Contains(searchString))

You are ready to run your application now, you should have something like the following:


Thank you 🙂

Keep It Simple & Straightforward.