Getting Start with UrbanCode Deploy with Patterns: A full-stack Application designer for Clouds

This blog post is about IBM UrbanCode Deployment with Patterns Blueprint and a how to guide, to help you manage the deployment solutions in the cloud that enables you to design, deploy and update full-stack environment for multiple clouds.

In the traditional on-premise IT teams are struggling to keep up with having to manage and deploy applications into various environments. It is a lot of work trying to get an environment and resources setup before we can start to deploy our application. Each deployment requires a lot of manual processes, where lots of people in the delivery pipelines such as the IT Architects and specialists need to be involved in setting up the virtual machine, network, storage, settings the different configurations in order to get the environment ready for applications deployment. This whole process of finding, setting up an environment and deploying the application can take an average of 3-4 weeks to complete. This is a lot of time wasted. As times goes by, the new business requirements came in and what if we need to make changes in the multiple environments in DEV, TEST and PROD, there are a bunch of manual processes and re configurations that needs to take place yet again.

Therefore in the new cloud business model such as pay-as-you-go in the Infrastructure as a Service (IaaS), it’s definitely a lot easier if we can get these resources from the Cloud. Cloud can help us speed up our development and deployment for new applications in the heterogeneous datacenter (private, public and on premise) as business operational demands increase or decrease very quickly.

This way, when we need an environment to deploy our application we can just simply request one through a cloud environment and have the environment provisioning for us without having to wait 3 to 4 weeks. When your business operational demands increase or decrease, you have an ability to add needed business application quickly and integrate and scale them up or down as needed.

In this series of blog post, I will be demonstrating to you how easy it is to use IBM Blueprint designer to:

Part 1: Create a Provision environment on clouds through OpenStack

Part 2: Deploy my application to the OpenStack environment on the cloud

The value BluePrint Designer brings

  • Design complete environment patterns that include your applications along with the infrastructure and middleware that supports them.
  • Enables specialist and integrators to capture their knowledge and expertise in the artifacts in the Heat Orchestrator Template (HOT) to represent the information about images, networks, storages and applications.
  • Capture the heterogeneous expertise of the total DevOps team, from solution architects to cloud infrastructure specialists
  • Manage and version those full-stack environment patterns through Git repositories, like you do with application source codes
  • Provision a full-stack environment in minutes from a pattern document that includes your application, the infrastructures, middleware and everything needed to run it
  • Cloud-portability through a blueprint. Ability to port your blueprint design in the different virtualized infrastructure to any cloud provider (OpenStack, Amazon EC2, SoftLayer and Vware Vcenter ) across the heterogeneous datacenter (private, public and on premise) as you wish.


  1. Blueprints Design Server is connected to OpenStack and also has already been configured to connect to UrbanCode Deploy (UCD) server
  2. IBM UrbanCode Deploy with Patterns is fully configured and it’s up and running
  3. OpenStack Cloud environment has already been configured
  4. User responsible for creating blueprint has been granted access to an OpenStack Cloud.

Note: Without the access to the OpenStack cloud environment, we will not be able to use UrbanCode Deploy with Patterns (UCDP) to access resources such as compute images, networks, storage and security from OpenStack to build our blueprints

Part 1: Creating and provisioning new Environment to OpenStack Cloud

In this section, we will be using a Blueprint designer to model, provision and update cloud environments from OpenStack Heat-based blueprints. We will be using a blueprint designer to describe topology of machine, network, storage resources and use the blueprint to provision and install UrbanCode Deploy agents, which references UCD components and processes.


How to use IBM Blueprint Designer to create a blueprint that we can then later on use to help us setting up a new environment to deploy the application on.

In this section you will:

  • Learn how to work with the blueprint designer
  • Lean to design a complete environment pattern that includes your application along with its infrastructure and middleware that supports them
  • Experience how a blueprint design can be designed by technical experts once and then be deployed and reused across the enterprise

At the end of this section you will have a blueprint that describe an environment. You defined Linux nodes, the networks that would be attached to the two Linux nodes and the software components to be deployed on each Linux system.

1.1 Create a Blueprint in Blueprint Designer

  1. Log on to your landscaper
  2. lanscaper.png

  3. Select Blueprint
  4. new_blueprint.png

  5. Click “New” in the add a new file dialog and type in your blueprint name and “Save” it. You will then be landed in the graphical editor mode of the blueprint.
  6. add_new_file

    Notice that on the right hand side of the blueprint designer, there is the palette for different resources for you to select from such as compute images, networks, storage and security from the OpenStack Cloud that you can just simply drag and drop into our design diagram canvas in the middle and start to build a blueprint for your environment.

    There are two methods that you can use for building your blueprint. The first method is via the graphical editor and the second method is via the Heat Orchestration Template (HOT) source code of blueprint directly.
    Caution: If you don’t see any of these resources that means, your UrbanCode Deployment with Patterns is not properly configure to access the OpenStack Cloud. You have to make sure that user who is responsible for creating the blueprint design has been authenticated to your OpenStack Cloud

  7. From the Network drawer of the palette on the right select and drag the networks that you would like to use with this blueprint. In my case, I am going to drag the private network to the designer’s diagram canvas.
  8. drawer.png

  9. Select the virtual image. Expand the images drawer; these are the images that are available on my OpenStack Cloud system. Drag and drop the Ubuntu1404x64 image onto the private network resource on the diagram canvas. This will automatically draw a connecter from the Private network to the image
  10. ubuntu.png

  11. Select the image to edit its properties and then select the pencil icon. Set Key and Name field to “dbserver
  12. db_server.png

  13. Repeat the previous step, drag and drop the Ubuntu1404x64 image onto the private network resource on the diagram canvas. This compute resource will be the host for my Websphere Liberty node
  14. Set Key and Name filed “appserver
  15. App_server.png

  16. Expand the Components drawer. Notice the components and tags that are available from UrbanCode Deploy server. When we drag and drop these components tag to our virtual machine, all of those components on the UCD server for those tags will be added to our blueprint.
  17. From the Component Drawer, I then select the MySQL Server component and drop it onto the first compute resource, which is “dbserver“. Basically, what I am doing at this step is that I’m adding the components from my UrbanCode Deploy server to the image.
  18. Choose UCD Application, “JKE” application is selected in the dialog that pops up, and click OK
  19. JKE_component.png

    Note: I need to choose the UCD application, so, that the UrbanCode Deploy server knows which application I am modeling. This will come in handy once we switch from a blueprint designer to UrbanCode Deploy Server later on.

  20. Repeat the previous step to add db component to the same compute resource.
  21. Next I will add the WebSphere Liberty Profile and war component to the second compute resource.


  22. Set the component process for MySQL server, select “CHOOSE” and select “deploy“. If I want, I could also give it a version name as well.
  23. deploy.png

    Note: that both of the compute resources for dbserver and appserver are connected to the private network. It means that they can access each other but will not be accessible outside the OpenStack server. To have the web application that is deployed on the Liberty node accessible from externally, I need to have OpenStack assign a floating IP address to the WebSphere Liberty node on the “public” network.

  24. In the Blueprint Designer, click the circle icon in the bottom-right hand corner of the Liberty Compute resource on the blueprint designer canvas to assign a floating IP to the node in OpenStack. Once it’s done notice that it will turn blue.
  25. static_ip.png

  26. Save the blueprint
  27. Next we will mark the deployment sequence order in which the UrbanCode deploy components should be deployed. Select the Policies drawer, and drag-and-drop Deployment Sequence onto each of the components in the sequence of

    1. MySQL Server
    2. db
    3. Websphere Liberty Profile
    4. war


    Note: If you set the deployment sequence incorrectly, you can click the Deployment Sequence icon of any of the component and change the sequence in the dialog.


  28. Save your current progress

1.2 Exploring the UrbanCode Deploy

  1. Open a new tab in your browser and type in the address of your UrbanCode Deploy Server.
  2. 1.1

  3. Login to UrbanCode Deploy with your credential
  4. IE: username: admin
    password: your_password

  5. In UrbanCode Deploy, select Components, and select the war component.
  6. Screenshot_3_2_16__12_28_PM.png

  7. Select the Configuration tab on the second row, and open the Environment Property Definition tab
  8. configuration_tab.png

  9. Notice that the default value for “ “is set to “localhost”.
  10. I will have to direct OpenStack to extract the value of the IP address allocated to the MySQL compute resource on the private network and set this as the value of the property.
  11. Switch back to the Blueprint Designer tab
  12. Select “war” component, set “” to “Private IP address for dbserver
  13. Private_iP.png

  14. Save the Blueprint. Now I have my blueprint to deploy my application and what cloud I want to deploy it on.


IBM UrbanCode Deploy with Patterns and OpenStack: Part I: Installing DevStack Kilo on Ubuntu 14.04.03 LTS for newbies

Even though, there are ton of instructions on the Internet on how to configure DevStack environment on Ubuntu 14.0.4 LTS. I have to admit that it took me several tries and many hours to troubleshoot my environment until I finally got the hang of it and to truly understand what was going on.

Since this is simply a test environment and I want to keep things very simple, I am going to use the same interface for all of OpenStack networks. In this blog post you will find a straightforward instruction on how to quickly setup OpenStack environment via DevStack. Once the OpenStack environment is up and running, I will show you how to quickly install and integrate with the IBM UrbanCode Deploy with Patterns so, that you can quickly:

  • “Stand up continuous delivery pipeline environment for new applications
  • Provision short-lived testing sandboxes for specific infrastructure
  • Promote infrastructure changes through environments just like application changes
  • Collaborate by composing the work of infrastructure specialists into full environment
  • Drive environment consistency from testing to production even when you are using multiple clouds” –

See the demo of UrbanCode Deploy with Patterns


  1. Download Ubuntu 14.04.03 LTS
  2. Install OS / Configure Ubuntu environment to have it ready for the OpenStack Environment
  3. Configure Ubuntu and Prepare for devstack configuration
    • $ sudo apt-get update
    • $ sudo apt-get upgrade
    • $ sudo apt-get dist-upgrade

DevStack Preparation

  1. Install Git
 $ sudo apt-get install git
  1. Clone devstack.git from branch stable/kilo
 $ git clone -b stable/kilo
  1. Create a localrc file in the root DevStack directory

# Logging

# Credentials


# Network ranges

# Heat

# Neutron Load Balancing

# Neutron Networking Service
disable_service n-net
enable_service n-cauth
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service horizon
disable_service tempest

Install DevStack

  1. cd into devstack directory
  2. Install Devstack
     $ ./
  1. If DevStack was successfully installed, you should see the following screen
            This is your host ip:
            Horizon is now available at
            Keystone is serving at
            The default users are: admin and demo
            The password: MyStack
  1. Confirming heat is responding (Note: We need an the heat orchestration engine to connect to each cloud system. If you don’t want configure Heat here you also have an option to have UrbanCode Deployment with Patterns to install the heat orchestration engine for you later on as well.)
     $ source admin-openrc

Note: admin-openrc file can be download by log in to the OpenStack Dashboard > Choose Your project> Compute > Access & Security > Open API Tab then click Download OpenStack RC File

  1. Make sure that heat service is registered with Keystone
 $ keystone service-list | grep heat
| 6326cd8a316743a79d77d5b9a0ee7bf9 | heat     | orchestration | Heat Orchestration Service   |
| 89333a24d6214a7283e08cbf86d56196 | heat-cfn | cloudformation | Heat CloudFormation Service |
  1. Confirm that Heat is running and responding
 $ heat stack-list
| id | stack_name | stack_status | creation_time |
  1. Generate a keypair for Heat to launch instances
 $ nova keypair-add heat_key > heat_key.priv
 $ chmod 600 heat_key.priv
  1. Launch a stack by running a heat stack-create

Note: Your image_id might be different than the example that I am showing here

 $ heat stack-create teststack -u -P key_name=heat_key -P image_id=cirros-0.3.4-x86_64-uec
+--------------------------------------+------------+--------------------+------------------| id             | stack_name | stack_status       | creation_time       |
| ffa93ba6-f1fa-43b0-8f8b-5e87c9b700f0 | teststack | CREATE_IN_PROGRESS | 2015-12-23T17:24:17Z |
  1. List Stacks
 $ heat event-list teststack
  1. List stack events


Extending the existing Heat Engines

We need to extend the existing Heat Engines that we have configured with DevStack so, that we can use it with the UrbanCode Deploy with Patterns

  1. Assuming that you already download the UrbanCode Deploy with Patterns
  2. Edit the configuration file for the engine at /etc/heat/heat.conf and uncomment /usr/lib64/heat and /usr/lib/heat (Note: In my heat.conf configuration file. I didn’t have any plugin-dirs parameters setup, therefore, I need to first create a plugin-dirs directory at /usr/lib/heat and update my plugin_dirs parameters in the /etc/heat/heat.conf to point to it.)
  1. From the UrbanCode Deploy with Patterns with Engine extract ibm-ucd-patterns-install/engine-install/chef.tar.gz file and then
     $ tar -xvf chef.tar.gz

    and then find the cookbooks/ibm-orchestration-ext/files/default/plugins.tar.gz file to the plugs-in folder

 $ tar -xvf plugins.tar.gz -C /usr/lib/heat/
  1. Restart the Heat Engine
 $ service openstack-heat-engine restart
  1. Restart the Heat API
 $ service openstack-heat-api restart
  1. Verify the new resource types from UrbanCode Deployments with Patterns are exist
 $ heat resource-type-list

Lists of the most common errors and solutions (Part 4)

Issue #1 After the Bridging-Header.h file was created. I tried to run my build but it failed with the following error message

/Users/mcj/Dev/PaleoRecipes/PaleoRecipes/PaleoRecipes-Bridging-Header.h:10:9: error: ‘CDTDatastore/CloudantSync.h’ file not found
#import <CDTDatastore/CloudantSync.h>
<unknown>:0: error: failed to import bridging header ‘/Users/mcj/Dev/PaleoRecipes/PaleoRecipes/PaleoRecipes-Bridging-Header.h’


1.   Check at your Bridging-Header.h file and to make sure that the import statement for the file not found is there.

#import <Foundation/Foundation.h>
#import <CDTDatastore/CloudantSync.h>
#import <CloudantToolkit/CloudantToolkit.h>
#import <IMFCore/IMFCore.h>
#import <IMFPush/IMFPush.h>
#import <facebookSDK/FacebookSDK.h>
#import “IMFFacebookAuthenticationHandler.h”
#import <IMFData/IMFData.h

2.   Check your Xcode project environment setting for deployment target. In my case, I have two targets build configuration PaleoRecipes and PaleoRecipesTests. if you look at my PaleoRecipesTests target build configuration it’s currently set to “None” and this is the root cause of why my build was failing.

PaleoRecipes_xcodeproj (1)

3.   To get rid of this error message. If you want to use the Pods on both targets like I do, I had to set my build configuration to Pods.debug and Pods.release. If you rebuild your project again this error should go away.


Creating a high-powered iOS apps with Bluemix (Part 3)

Part 3: Instrument the Client App

In this section of the tutorial, we will be instrumenting the client application so we can start recording data for monitoring and gather user statistics about the client mobile application usage in the IBM Advanced Mobile Access dashboard. Once that is done, we will move on to how to setup the Push iOS 8 notification to use the Apple Push Notification (APN) services. We will subscribe to notification tags and run our tests to confirm that the push notification message is successfully delivered to our end users.

6. Instrument the client Application for App Monitoring

We will be instrumenting the client application so we can start recording data for monitoring and gather user statistics about the client mobile application usage and view it in the Bluemix dashboard.

6.1 Enable the logging and Analytics and view it in the Bluemix dashboard. First, we must send log data to the server by copying the following function to the AppDelegate.swift file.

func applicationDidEnterBackground(application: UIApplication) {

// Consider if these calls should be in applicationDidEnterBackground and/or other application lifecycle event.

// Perhaps [IMFLogger send]; should only happen when the end-user presses a button to do so, for example.

// CAUTION: the URL receiving the uploaded log and analytics payload is auth-protected, so these calls

// should only be made after authentication, otherwise your end-user will receive a random auth prompt!

IMFLogger.send() // send all IMFLogger logged data to the server

IMFAnalytics.sharedInstance().sendPersistedLogs() // send all analytics data to the server


6.2 Set debug levels by calling the IMFLogger setLevel Function. For this tutorial we will set the IMFLogger to enable crash capture.

6.2.1 copying the following code to func applicaton(application: UIApplication, didFinishLaunchingWithOptions launchOptions:NSDictionry in the swift file

//Analytics and Monitoring

IMFLogger.captureUncaughtExceptions() // capture and record uncaught exceptions (crashes)

6.3 Capture logs from your application only and exclude logger entries from the IBM MobileFirst SDK codebase. In order to do that, we need to set the filter on the IMFLogger to allow login only for your package AppDelegate.swift file

6.3.1 Set the IMFLogger, add the following lines of code right after step 6.2.1

IMFLogger.setLogLevel(IMFLogLevel.Error) // setting the verbosity filter. Change to Info to get more logging output

IMFAnalytics.sharedInstance().startRecordingApplicationLifecycleEvents() // automatically record app startup times and foreground/background events

logger = IMFLogger(forName: “yourAppName”)

6.4 Run your test for the App Monitoring by launching your app by clicking on the run button from your project navigator and then switch to your Bluemix dashboard > Advanced Mobile Access. You should be able to view the device logs, Authentication, etc directly from the Bluemix Dashboard

Mozilla_Firefox (1)

7. Setting up Push iOS 8 Notification

To use the Apple Push Notification (APNs) services, we will need an SSL certification, which is required for each environment (sandbox and production). The certificates that are needed for APNs are .p12 certificates. If you haven’t generated your certificates already, you will need to log on to the Member Center of the Apple Developer Website and then generate your SSL Certification.

7.1 Configuring for Apple Push Notification (APN) service

An SSL certification is required for each environment. We will need to obtain the certificates from the Member Center of the Apple Developer

7.1.1 Bring up your web browser and go to the Apple Developer Website

7.1.2 Go to > Certificates, Identifiers & Profiles


7.1.3 Click > Certificates > Development> Add > iOS App Development > Next


7.1.4 Create a Certificate Signing Request (CSR) file

Please see all the steps on how to manually create a CSR file in the screenshot down below. Once the CSR file is successfully created Click > Continue

Add_-_iOS_Certificates_-_Apple_Developer (1)

7.1.5 Generate your certificate

Upload a CSR file that was previously created in step 7.1.4 and then Click > Generate


7.1.6 Download this certificate to your computer

Add_-_iOS_Certificates_-_Apple_Developer (2)

7.1.8 Go to Identifier Section > Create an App ID > Check Push Notification for Development SSL Certification then Click Create Certificate and then save it to your computer. You will need this certificate in order to create the .p12 file

7.1.9 Go to Devices Section and register device. You will need to the UUID of your iOS device.

The UUID is unique device identifier that was assigned to each iOS device. To get the UUID, bring up the iTunes Application > Select your iOS device > Summary > Click on Serial number until you see that it switches to UUID

To copy UUID, go to Edit > Copy UUID

7.1.10 Go to Provisioning Profiles section and create a profile for development and download it to you computer

7.1.11 Double Click on the .cer file that you have just download

7.1.12 From Keychain Access > select Key and look for the profile name that you have created in step 7.1.4 and 7.1.5

7.2 Generate .p12 file

7.2.1 Double click on the .cer file that you have just download from step 7.1.10

7.2.2 Applications > Utilities > Keychain Access > Key look for the profile name that you created in step 7.1.4 and 7.1.5

7.2.3. Expand Private Key profile and you should see the certificate file that you just added


7.2.4 Select both the private key and certificate > click “Export 2 item” and make sure that you save the file formate to .p12 file


7.3 Configure the Push iOS 8 Notification in Bluemix

7.3.1 Bring up a browser and bring up your Bluemix Project Dashboard

Dashboard_-_IBM_Bluemix (3)

7.3.2 Click the Push iOS notification > Configuration > sandbox

7.3.3 Upload the SSL Certificate (.p12) that we previously create to Bluemix then click > Save


7.3.4 Click on Tags > CREATE TAG, enter a tag name “Push Notification” then click SAVE

Push_Dashboard (1)

8. Set up the iOS development for Push iOS 8 notification

From your xc.workspace, Open your <appName>.plist and validate the applicationId, applicationRoute and update the applicationSecret and variables to match the identity provided by the IBM Bluemix for Push iOS 8 notification.

Note: If you are getting the following error message

2015-08-19 14:20:43.471 PaleoRecipes[4388:1842585] You’ve implemented -[<UIApplicationDelegate> application:didReceiveRemoteNotification:fetchCompletionHandler:], but you still need to add “remote-notification” to the list of your supported UIBackgroundModes in your Info.plist.

  • From the Project Navigator > click the project
  • Select > Targets then Click> Capabilities tab
  • Expand and turn on Background Modes
  • Select > Remote Notification

PaleoRecipes_xcodeproj (2)

9. Running Test for the push notification

Next we want to make sure that the push notification is working from the client application and from the Bluemix Dashboard. We want to manually push the message from the Bluemix application to all of the registered devices and validate that our message will get through.

9.1 Testing for the notification from the Xcode project

Note: This can’t be done via an iOS simulator. You will need to connect the iOS device into your machine to run the test.

9.1.1 Connect the iOS device into your machine

9.1.2 From Xcode > Select the device from the drop-down list

9.1.3 Select your application under the Targets make sure that there is no warning or error message regarding the code signing

9.1.4 Switch to the Building setting tab, search for provisioning profile and make sure that you are selecting the provisioning profile that you created from section 7.1.10

PaleoRecipes_xcodeproj (1)\

9.1.5 Run the app, when app starts, click on setting Screenshot_8_19_15__3_53_PM icon and slide the switch to turn on Notifications and subscribe to the subscription tag that you had previously created in step 7.2.4


9.1.6 Allow Push Notification > Select Yes


9.2 Manually Push Notification from the Push Notification Dashboard

Note: To see the push notification message that you will send to your iOS device, from your iOS device, press home button and put the app in the background.

9.2.1 Go to Notifications > SEND NOTIFICATION > select All registered mobile devices > Next

9.2.2 Type in Message Text “Push notification ” > SEND

Push_Dashboard (3)

Creating a high-powered iOS apps with Bluemix (Part 2)

Part 2: Getting Started with Bluemix & iOS Development

In this section of the tutorial, you will learn how to:

  1. Create a mobile application backend on Bluemix for the iOS development which include the Node.js as a running and pre-built services such as Advanced Mobile Access, Push iOS 8 Notification and Cloudant NoSQL DB in order for you to start assemble your apps faster
  2. Register you existing Xcode project to Bluemix
  3. Install IBM MobileFirst Platform for iOS client SDK and start to leverage the different frameworks provided by the IBM MobileFirst Platform for iOS
  4. Configure the authentication mechanism to access the backend services in the Advanced Mobile Access dashboard
  5. Configure the app in Xcode for Facebook Authentication to access the backend services.

1. Create an iOS 8 app in IBM Bluemix™

    1.1 Log on to the IBM® Bluemix

    1.2 Enter your app name


2. Register an existing Xcode project to Bluemix

At this step, we will be registering the existing Xcode project to IBM Bluemix. It is very important that you enter the right Bundle ID and version number of your Xcode project.

2.1 Select Existing Xcode Project
2.2 Enter the Bundle ID and Version number of your Xcode project


Note: Bundle ID and Version number of your Xcode project can be found if you bring up Xcode Project > General> Identity


2.3 Initializing SDK with IBM Bluemix App ID and Route
Next, we need to connect the client application with the iOS 8 app that you just created in the Bluemix Dashboard.

To connect your client application with the mobile app in the Bluemix dashboard, we need to copy the Bluemix App ID and Route, which is provided by Bluemix to our project.
From your xc.workspace, Open the PaleoRecipes.plist and update the applicationId, and applicationRoute variables to match the identity provided by the IBM Bluemix.

2.4 Click > DONE
An iOS application is successfully created on Bluemix using Node.js as a runtime and bind with three services, which are:

1. Advance Mobile Access for security to the backend resources and monitoring of the client logging and statistics

2. Push iOS 8 notification, which provides the capability to use iOS 8 features for managing and interacting with notifications in your application

3. Cloudant NoSQL DB, which is a NoSQL database as a service (DBaaS) that can handle many types of database types such as JSON, full-text, and geospatial.

Dashboard_-_IBM_Bluemix (2)

3. Install the IBM MobileFirst Platform for iOS client SDK using CocoaPods

There are two ways that you can set up your client development environment. You can use CocoaPod or Manual Installation. For this tutorial, we will be using the CocoaPod dependency manager.

The CocoaPods dependency manager is a dependency management tool for iOS and OS X development for Swift and Object-C Cocoa project. CocoaPods make adding and removing dependencies for an iOS/OSx developer project a lot easier. In this section you will see that we will be defining our project dependencies in a Podfile and then use the “pod install” command to install the required dependencies for the IBM MobileFirst services.

But before we can use the ‘pod install’ to install our dependencies for IBM MobileFirst services, first we need to make sure that CocoaPods is setup.

3.1 Setup CocoaPods, if you haven’t done so already by running the following command from the terminal

$ sudo gem install cocoapods

$ pod setup

3.2 Create a Podfile. From a terminal, go to your app folder then run

$ touch Podfile

Note: Below is a standard Pod file for using IMF services, we only need to include the resource we need and remove the dependencies that we don’t need

source ‘;

# Copy the following list as is and remove the dependencies you do not need

pod ‘IMFCore’
pod ‘IMFGoogleAuthentication’
pod ‘IMFFacebookAuthentication’
pod ‘IMFURLProtocol’
pod ‘IMFPush’

3.3 Install the dependencies, run “pod install”

$ pod install
Oyster$ pod install
[in /Users/Oyster/Dev/PaleoRecipes]
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
Installing Bolts (1.2.0)
Installing CDTDatastore (0.14.0)
Installing CloudantQueryObjc (1.0.2)
Installing CloudantToolkit (1.0.0)
Installing CocoaLumberjack (2.0.0-rc)
Installing FMDB (2.3)
Installing Facebook-iOS-SDK (3.23.2)
Installing IMFCore (1.0.0)
Installing IMFData (1.0.0)
Installing IMFFacebookAuthentication (1.0.0)
Installing IMFPush (1.0.0)
Installing IMFURLProtocol (1.0.0)
Generating Pods project
Integrating client project
Sending stats

3.4 Create a Bridging-Header.h file

We need to access the IMF Object-C code from SWIFT. Therefore, we need to create a Bridging-Header.h to expose the IMF Object-C code to SWIFT code. To create a Bridging-Header.h file

3.4.1. Open your (AppName).xcworkspace
3.4.2. Click Project File > New file> iOS > Source> Header file
3.4.3. Name your file <AppName>-Bridging-Header.h (Note: The prefit of your Bridging-Header.h file must be exactly the same as your project name)

3.4.4 In the -Bridging-Hearder.h, remove the following lines of code

#ifndef _PaleoRecipes_Bridging_Header_h
#define _PaleoRecipes_Bridging_Header_h

3.4.5 Add the import statements to expose the Object-C headers that we want to expose to the header files that we just created and save it.

Note: Below is a standard Bridging-Header.h file when using the IMF services. (You only need to include the ones you require)

#import <Foundation/Foundation.h>
#import <CDTDatastore/CloudantSync.h>
#import <CloudantToolkit/CloudantToolkit.h>
#import <IMFCore/IMFCore.h>
#import <IMFPush/IMFPush.h>
#import <facebookSDK/FacebookSDK.h>
#import “IMFFacebookAuthenticationHandler.h”
#import “IMFGoogleAuthenticationHandler.h”
#import <IMFData/IMFData.h>

Once all the required dependencies has been installed and configured correctly. We will be able to register the client to the backend using the
IMFClient.sharedInstance().initializeWithBackendRoute(applicationRoute, backendGUID: applicationId)

3.5 In the Build Setting tab, we need to set the Object-C Bridging Header setting under SWIFT compiler to point to the Bridging-Header file that you just created

Tip: To quickly search for what you are looking for type in the word “swift” in the search field


3.6 Call the IMFLogger API from within a Swift project.

4. Client Registration for Advanced Mobile Access Service

4.1 Client Registration

At this step we will have to configure and select which authentication mechanism we will be using for back-end access. By default it’s currently set to unauthenticated. To configure the app to use a different authentication mechanism such as Facebook, Google or Custom authentication

4.1.1 Click on Advanced Mobile> Click Allow Unauthenthicated access to the back-end resource

AMA_Dashboard (2)


AMA_Dashboard (3)

4.1.3 Select Authentication Mechanism for Facebook

Note: There are three types of authentication mechanisms that you can use for authentication with the backend resources, which are FaceBook, Google and Custom. For more details on how the iOS app handles the authentication, please see AuthenticationController.swift created by the IBM’s MobileFirst team for more details.

AMA_Dashboard (5)

4.1.4 Enter Facebook App ID > Click SAVE

Note: If you don’t have the Facebook App ID. You can find more detail over here (Quick Start for iOS)

AMA_Dashboard (4)

4.1.5 You should see a client registration page confirmation similar to my screenshot down below


5. Configure the app in Xcode for the Facebook Authentication for the Advanced Mobile Access

Since we are using Facebook as an identity provider to gain access to the Advanced Mobile Access resources. We will need the Facebook App ID in order to configure both security for Advanced Mobile Access service and the Mobile iOS application. At this step we will be modifying the existing Info.plist file. Please see Quick Start for iOS for more details.

  • From the Xcode Project >Open Info.plist file
  • Info.plist should be in the Supporting File Folder inside your Xcode Project
  • Create a new key for FacebookAppID with String as Type and enter the FacebookAppID
  • Create a new Key for FacebookAppDisplayName with String as type and enter the FacebookDisplayName
  • Create a key for URL Type with Array as Type with a dictionary as its only child. Dictionary also needs one array called URL Schema. The child of that array is a string of the facebookID app precedes with the fb in front


  • Open the AppDelegate.swift and override the application:openURL:sourceApplication:annotation as follows:

func application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject?) -> Bool {

return FBAppCall.handleOpenURL(url, sourceApplication: sourceApplication)



  • Add the following line to the applicationDidBecomeActive This is a function that will restart any task that was paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface


AppDelegate_swift (1)

  • Registering the “IMFFacebookAuthenticationHandler to enable iOS application to respond when Advanced Mobile Access requires a Facebook log in. “Advanced Mobile Access provides a delegate by default and logs in to Facebook with read permission to the user’s public profile.”- IBM Documentation

To register the default delegate, add the following SWIFT code to AppDelegate.swift to initiate security for user authentication for the client. This code should be copied to func applicaton(application: UIApplication, didFinishLaunchingWithOptions launchOptions:NSDictionry

// Register a default delegate.

// Logs in to Facebook with read permissions to the user’s public profile.


  • Now run your application to test out the authentication method. You will be prompted for the Facebook Authentication. Enter your email or phone > Enter password


  • Once you are successfully authenticated, you should be able to see the first screen of the Mobile App

Creating a high-powered iOS apps with Bluemix (Part 1)

Learning how to write iOS app in SWIFT language has been something I have been intrigued with for quite sometime. There is something extraordinary about committing yourself to learning something new and sharing what you learned with the rest of the community; the questions is just a matter of when and how?

Finally, I took the plunge. I created a sample app that will allow me to keep track of all the recipes that I have made at home.

Before I continue, let me be clear that I am NOT an expert in SWIFT programming language by any means. This is purely a proof of concept with the intention of sharing what I have learned while developing my iOS app as much as possible with the rest of the community. In addition, as a cloud specialist for the IBM Cloud business unit, I want to experience first hand how easy or difficult it is to start developing iOS application in Xcode. Later on I want to move my development environment to IBM® Bluemix cloud environment platform and start leveraging the different services that are available on the cloud to my existing app. What is the best way that I should go about this?

In this three-parts tutorial you will see how IBM MobileFirst helps you delivery high-powered iOS apps sooner and faster by leveraging the different Bluemix services versus having to write and maintain those services by yourself.

Part 1 , How the sample app works and pre-requisites before you begin

Part 2 , you will learn how easily developers can add IBM MobileFirst SDK to an existing mobile app with just a few lines of code.

Part 3, you will see how easy it is to start leveraging the different type of services such as Advanced Mobile Access and Push iOS 8 notifications to your existing iOS app.

What You Will Do in the tutorial

Part 2: Getting Started with Bluemix & iOS Development
1. Create an iOS 8 app in IBM Bluemix
2. Register an existing Xcode project to Bluemix
3. Install IBM MobileFirst Platform for iOS client SDK
4. Client registration for Advanced Mobile Access
5. Configure the app in Xcode for the Facebook Authentication for the Advanced Mobile Access

Part 3: Instrumenting the client app for Monitoring and Push iOS 8 Notification
1. Instrument the client Application for App Monitoring and Statistics
2. Configure the iOS 8 Push Notification on IBM Bluemix
3. Set up the iOS development environment for Push iOS 8 notification
4. Run your tests for push notification

How the Sample App Works

This sample iOS application called MyYummy Paleo is an app that user can use to keep track of their favorite paleo recipes that they love, review the recipe and then post their review and picture of the meal to Facebook.

When the user first launches the app, it will prompt a user to enter their Facebook login and password. At this point if you are using an app for the first time, you will have to enter your Facebook id and password as an authentication.


Once a user is login and successfully authenticate. In the root view, user can add a new recipe, view all the recipes, write a review of their recipe and read all the reviews that they have written.

To upload the recipe, tap the “Add Recipe” row in the table view


  • Enter the recipe name
  • Enter a meal preparation time
  • Enter cooking time
  • Enter servings
  • Enter all the ingredients for this meal
  • To add the picture of this meal, you can just simply click “Add Recipe Image” or tap on background below the Add Recipe Image to add a photo
  • Then click “Save” to save a recipe


To view a recipe, select “All Recipes” in the table view. When a user selects an item on the table view, they will be able to make changes to a recipe, add all the ingredients, correct any typo and/or add new picture. Once a user clicks save. It will bring a user back to a previous view.

Screenshot_9_21_15__3_29_PM (1)

From Recipes’ table view, when a user makes a swiping gesture of the item on the table view, a user will be able to delete the recipe from the sample app.

Screenshot_9_21_15__3_26_PM (1)

In addition a user can also, write a review and rave about what they love about a meal that they just made and then share with their friends on Facebook through the app.

To write a review, go back to the root table view and select tab on “Write Review“, select meal category, write a review and add a picture, then save it.


To read all of their meal’s review, select “Read Review“. When you select an item on a picture on the reviews’ table view, a user will be able to review what they wrote and then post their review, along with a picture of that meal to their Facebook page.

iOS_Simulator_-_iPhone_5s_-_iPhone_5s___iOS_8_3__12F70_ (1)

iOS_Simulator_-_iPhone_5s_-_iPhone_5s___iOS_8_3__12F70_ (2)


Before you start the tutorial, review the following steps for detailed information on prerequisites. Some activities such as registration for IBM Bluemix and create the Facebook AppID should be completed ahead of time.
You will need the Facebook AppID to configure the authentication mechanism to access the backend services in the Advanced Mobile Access Dashboard and preference settings for your app in the Xcode project.

  1. Registered for IBM® Bluemix. If you haven’t already, you should register now.
  2. Setup a new Facebook AppID

    All_Apps (2)

    • Select iOS

    All_Apps (1)

    • Enter Facebook App Name then Click Create New Facebook App ID


    • Select App Category then Click Create App IDQuick_Starts (1)
    • Make note of your FacebookAppID and FacebookDisplayName, because later on we will need these two values to configure the Info.plist file in Xcode project
    • Scroll down and Enter the Bundle Identifier Name of your Xcode Project and Click> Next
    • Quick_Starts (3)

Scroll Back to the Top and Click > Skip Quick Start then you will see an App Dashboard

Using Scrum Methods with IBM DevOps Services

Note: I co-authored this with Daniel Toczala, so you can also find this on his WordPress blog, dtoczala.

This article is in response to a number of frequently asked questions about sprint planning and scrum methods, as well as some links to other resources we have created or found to answer those requests.  Before we dive deeper into the topic, let’s take a quick look at what type of scrum work items are provided in IBM DevOps Services. If you have never used any scrum methods before, this can be overwhelming at first.  That’s OK, just read through this and try to digest as much as you can.  If you are familiar with Scrum and Agile methodologies, just skim through all of the explanations to get to the meat on how to do things with IDS.

We call out some sections of this whole process in this indented green text.  These represent best practices, or areas where you can dive more deeply into how IDS works.

You might also note that a lot of the links for terminology in this article lead to Wikipedia references.  It’s not because we love wikipedia, it’s because too many of the good articles out there have a lot of product references (like this one does – with IDS).  I went looking for some content that was tool agnostic – and Wikipedia is often the best bet for that type of material.

Before We Begin
If you haven’t already registered for IBM DevOps Services (IDS) and Bluemix, you should register now.  It will help you follow along with our examples and will allow you to try a few things for yourself.  You can use IDS alone, use Bluemix without IDS, or use them together.  You may have used the Scrum Process with Rational Team Concert in the past.  If you did, then a lot of this will look quite familiar.

Getting Started with IBM DevOps Services (IDS)
Once you have registered with IDS, you will want to create a project.  To do this, Go out to your IDS dashboard.  Click on Create a Project.  You will see a new project dialog come up. Give your project a name (like “Sample Scrum Project”), something that will identify it. Select where your source code repository will be.  For the purposes of this article, it doesn’t really matter, since we’ll just be looking at some common Scrum methods, and will not be dealing with code. Then make sure that you have a checkmark in the box for “Add features for Scrum development”.  If you are an adventurer, and want to play around with some code, and then deploy it to Bluemix, you might also want to check the box for “Make this a Bluemix project”. Finally, hit the “Create” button in the lower right, which will create your new scrum project. So now we have a Scrum project created, and you can see it in the browser.  Now we want to set it up correctly.

In the future, we’ll want to add other members of our team to this project.  To do this, just click on the link for “Members” on the left hand nav bar, and then click on the “Invite Members” icon to add members of your team to the project.

Right now, we just want to learn how to use IDS in conjunction with some common Scrum practices.  One of the first things you’ll need to do is to decide on the length of time of each of you iterations.  In Scrum, these are called Sprints.  Each Sprint represents a period of time where the development team will develop and test code, and commits to have an executable application at the conclusion of the sprint.  That means that you have a running application at the end of each sprint.  It may not expose all of the functionality that has been developed, and some functionality may not be present, but it will execute.

Most scrum teams run with 2 week sprints.  To set up your sprints, start on the overview screen, and press the button labelled “Track & Plan”.  Once on this screen, select “Sprint Planning” from the nav bar on the left.  Since you have just started your project, you don’t have any sprints right now.  So let’s create some.  Click on the “Add Sprints” button in the Sprint Planning window, and add 4 new sprints, and make them 2 weeks in length.

If you click on “Edit Sprints” at this point, you can see how you can now go and add new sprints, rename your sprints, and change the dates on your sprints.  When working with IDS, we suggest naming your Sprints the same as the end date of the sprint.  That way your stakeholders who are unfamiliar with Agile can look and see when their user stories will be implemented at a glance.  They really don’t care about sprints or Agile development, they want to know when they can expect things.

Defining Your Initial Work
Now you have the basic project setup done.  It’s now time to start thinking about doing actual work.  The first thing to understand is the different types of work items available to you to capture your work.

Work Item Type What it is used for
Story (Sometimes called User Story) A user story is a description of some functionality needed, told from the perspective of the end user of the application. Some people find this equivalent to a use-case.
Task Tasks are single user tasks used to accomplish some well defined and well scoped effort. Stories are typically broken down into the multiple tasks, representing the work needed to accomplish the implementation of a Story.
Epic Epics are stories that are too large to be contained within a single sprint. Typically an Epic can be broken down into two or more Stories.
Defect Defects are bugs, problems with the application. Many Scrum teams will treat them similar to how they treat stories, by decomposing them into the tasks needed to be done to fix a particular defect.
Impediment These are the risks, issues, and environmental factors that stop work from being accomplished. Typical impediments may include things like waiting for properly signed SSL certificates, waiting on hardware availability, lack of stakeholder availability, and other similar situations.
Adoption Item Adoption items indicate when changes made by one team need to be accepted (and integrated) with another team. An upgrade to a new database version is an example of this.
Retrospective Retrospectives are held at the end of each sprint, and they allow the team to reflect on what is working well, and what isn’t working well. It is an attempt to keep the team focused on continuously improving their effectiveness. Retrospective work items capture the notes and observations made by the team during a retrospective.
Track Build Item Used to track builds, and relate them to them functionality that they will deliver. Not a lot of teams use these.

So at this point you should begin creating user stories, epics, impediments, and adoption items for all of the work that you are aware of.  Just click on the “+” in the backlog box to begin creating your first work items.  Once you click on it, just type in a brief headline or general description of the work.  Don’t worry, you will be able to fill in more detail later.  Click on the small icons below the text, to change the work item type, add a more detailed description, and so on.  As you add work items, they will begin to display in your team backlog.


The edit sprints button, some text for a first work item, and the icons to change the work item attributes

Backlogs are a critical part of scrum development.  Your backlog contains all of the work that your team thinks that it may need to do, but that the team has not yet committed to doing.  If you haven’t scheduled it, and assigned the work to a particular sprint, then it should be in the backlog.  Mature products may have backlogs with 100 or more items in them.  We’ll discuss how to manage your backlog in the next section.

After you have created your initial work items, take a look at your backlog.  It should show all of your work items.  Click on any individual work item, and you will see the details about that work item.  Go back to your sprint planning view, and you will see the work items displayed along with some summary information.

When looking at the details of a work item, it is important to note the fields in the work item.  All of them are self-explanatory, but they do impact how your team does it’s work.  Often lists that are displayed (like your backlog) will have higher priority items at the top.  The discussion field is used to discuss work items, and to provide a running status on the work items.

When you want to ask someone something in a discussion, click on the link icon with a person, and you will get a dialog where you can choose the specific person that you want to identify.  Now once you save your changes, that person will get an email notifying them that you have asked them a question, along with a link to the workitem.

If you have people always asking about the status of some work, just go to the links tab on a detailed work item, and add that person as a subscriber.  You can add yourself or other people as subscribers to a work item.  whenever a work item is modified, all subscribers get an email that notifies that of the modifications made to the work item, as well as a link to the work item.  We end up using much less email, and having far fewer status meetings, because by using subscribers we are able to keep everyone informed on the progress of critical work items.

Backlog Management
Let’s face it; even though we try our best to estimate things, we’re often very wrong.  We’re not wrong because we are dumb, we’re wrong because we don’t have enough information.  So when using Scrum, we look at each story on our backlog, and we estimate the size/complexity of the story using story points.  Teams will use various methods for estimating story points (some use Planning Poker).  The way that we size the story is very easy and straightforward. If you think that the user story can take a short amount of time to complete, then you give it a low number. If you think it’s going to take a lot of effort to get the user story done, then you give it a high number.  As time goes on, you will get a better feel for estimating work in this way.  You can do all of this work while in that same sprint planning view, capturing your decisions and discussions in the work items as you go along.

There is heated debate about assigning story points to user stories.  Some people think that it is a measure of risk and complexity, some think it is a measure of difficulty, some think of it as a measure of effort.  Do what works for you.  I like Michael Tang’s quick view of story points, but you can find other viewpoints from Mike Cohn and others.  Just spend 30 minutes Googling this and educate yourself.

Once you have estimated the relative sizes of your stories, you are now ready to do some backlog grooming.  In the left hand nav bar, you will notice a link called “Backlog”.  Click on that link, and you should see a nice list of all of your stories.


Backlog Grooming Example

Now we can begin grooming this backlog.  Drag the most important story, the most critical one, to the top of the list.  Now drag the second most important story, and drop it below the first story.  Keep doing this until you have a ranked list of your user stories.

Clicking on a user story will bring up details about it, which you can use when discussing them.  Be careful when dragging and dropping user stories.  If you drop a user story on top of another user story, it will make that user story a child of the user story it was dropped on.  Sometimes you want to do this.  If you didn’t want to do this, then click on the small plus sign “+” on the left of the user story, which will display it’s children.  Then click the small “x” on the left of the child user story, to remove it from being a child.  If you drop it in-between two user stories, it will get ranked between them.

This is your ranked backlog.  This is a critical step for your team, because this indicates the relative priorities of the work that you have been asked to do.  When we get into sprint planning in the next section, you will see how we look at the top of the backlog when planning our next sprint.

Backlog grooming is an important and ongoing activity.  Some scrum teams will do backlog grooming once per sprint, others will do it monthly, and still others will try to do it on an ongoing basis.  The thing to remember is that stories on the backlog need to be reviewed periodically, to ensure that the estimates are accurate, and that the business and development environment have not changed and impacted their priority in relation to other stories on the backlog.

Sprint Planning
Now we get to the key piece of software delivery planning, Sprint Planning.  In your IDS browser, in the left hand nav bar, click on the link called “Sprint Planning”.  When you do this, on the left hand side you will see the ranked list of your backlog items, with the highest raked items on top (I told you that backlog grooming was important!).  On the right hand side you will see an empty list, which represents your first sprint.  Now at this point, you would begin to drag user stories and work items from the backlog (on the left), to your sprint (on the right).  Go ahead and try it.  Move the top ranked user story from the backlog to your sprint.

When you do this, you will notice some changes.  Now in the right hand list, click on the link for “Team Progress”.  What should you see?  Well you should see that the story is now scheduled to be done during the first sprint.  You’ll also notice that the story points assigned to this story show up in the team progress (you now show as having completed 0 out of x story points).  Observant users will also see that the ranked list has updated, and that the next item on the backlog now has a ranking of 1.

Continue to assign stories to your first sprint for what your team can GUARANTEE that they will finish in the timeframe of the first sprint.  That means COMPLETELY FUNCTIONAL software that satisfies the user stories.  Do not over-promise – this is your team’s commitment to complete the work in the timeframe of the first sprint.  Keep in mind that you’ll also have to do testing, and that some bugs may pop up and need to be done as part of the work of this sprint.

The amount of story points that a team can normally complete within a single sprint is called the Team Velocity.  You need to have a gut feel for how much your team can do in your first few sprints, until you get enough history of doing Agile development to understand the velocity of your teams.  Once you have this history, it is easy to assign work to sprints up to three of four sprints in the future, because you have an understanding of how your teams perform.

There is a pile of articles and blogs on Sprint Planning.  What we have seen work the best is when teams commit to doing about 60% of their capacity in a sprint.  This leaves them time for unanticipated surprises, bugs, and other things. It also allows them to build confidence and meet their commitments.

If a team notices that they are half way through their sprint, and that they are almost done, they can then go back to the backlog (or even a future sprint), and pick one or more appropriately sized stories to complete early, in the remaining time that they have in this sprint.  Nobody has ever complained about getting functionality early.

Sprint planning is only half done at this point.  You now have a set of user stories that you are committing to implement in your sprint.  But HOW are you going to do it?  You’re going to have the entire team take those user stories and break them down into the discrete tasks needed to implement those stories.  Look at your sprint backlog now, and on the top story click on the icon for “Open child task breakdown”.  You’ll see that label when you hover over the icon.


Sprint planning – creating the tasks for your user story

Once you click on the icon, a new screen appears.  This is your area to enter all of the child tasks for the story that you are breaking down.  You should just click on the plus sign to create a new task work item, that will be a child of the user story that you selected.


Starting your work item entry – use icon to designate this as a task

As you enter in some text to define your new task, you’ll also notice some icons below the text area.  Use the icon on the far left to set the work item type.  In our case, we will want to make this a task.  Notice that this adds some additional “shorthand” to your task description.  Try the other icons, and become familiar with the attributes that you can change in your work item.

At this point you should be getting used to how the work items work within a sprint.  You could easily decompose a large story into smaller stories, making them children of the larger story.  Don’t go crazy with parent-child relationships, use them where it makes sense.  It can be effective to have everyone looking at the same screen during these planning meetings, so the whole team is aware of the tradeoffs discussed, and the whole team has input on the estimates and work breakdown.

Use the icons to set attributes for your work item

Use the icons to set attributes for your work item

Work with your team to define all of the tasks needed for the completion of the user story.  When you are done, you should have a list of tasks that are in the Open column.  Now click on the small down arrows at the bottom of the first task in the list, and you will see some detail information for your task.  You and your team should now look at estimating how much effort each task will take.  You can also further clarify things if you need to.

Adding estimates to your tasks

Adding estimates to your tasks

Go through all of the tasks for this story, and then do the same exercise with your team for the remainder of the stories in your sprint.

At this point you are almost done with your Sprint planning.  You now need to go back and review what you have done, and check your estimated work against the calendar.  Navigate back to your original sprint planning page, and then click on the link for Team Progress.

Checking your sprint estimates

Checking your sprint estimates

You will see that you have an total of the estimates of all of your tasks in hours displayed, a number of work items assigned to the sprint, and a total of the story points.  These are all represented as the second number (0/n) in those progress indicators.  Make sure that you have not overcommitted to the sprint in terms of hours (a two week sprint, means 80 hours of work for each person on the team), or in terms of story points.  Also make sure that you have not undercommitted, and if you have, look for additional stories off of the backlog that you can assign to this sprint.  You’ll spend the remainder of your time in sprint planning making adjustments.

In a lot of the literature on Sprint Planning, they discuss a Sprint Backlog (which is what you are building here), and a Product Backlog (which we just call a Backlog here).  The terminology can be confusing, but in the end the important thing is that you commit to right amount of work for your sprint, and that you correctly define that work for your team.

When do we start doing work?
All of that effort, and we have not written a single line of code.  Ugh!  It can be tough sometimes for people eager to dive in and start prototyping and coding.  Planning is important – it helps us focus on the things that will bring value to our stakeholders and to the business.  There is nothing worse than working long and hard on something that never gets used, or has no value.

The daily scrum
So now that everything is planned, we can kick off our first sprint.  Most Agile teams will have a daily standup meeting.  The daily standup (or scrum) is a chance for each member of the team to briefly talk about what they are doing, what they plan to do, and any impediments or obstacles to their achieving these goals.  These are sometimes referred to as The Three Questions.  It isn’t a status meeting.  It’s a chance to share technical news, and other team members are encouraged to share information that can help other members of the team.  The daily standup can be run in a number of different ways, and there are a lot of mistakes that you can make in how you conduct these meetings.

Most people suggest running these daily standup meetings in front of the scrum taskboard.  You can do this with IDS by using the Team work view.  Just go to the original sprint planning view, and look at the nav bar on the left.  In the nav bar, there is an entry for “Team’s Work”, click on it and you will see the team view of the work in your sprint.

Scrum task board - with viewing options highlighted

Scrum task board – with viewing options highlighted

By choosing the viewing option icons at the top right of the view, you can look at your work as a list, as a table, or in lanes.  Most mature scrum teams will choose to view things in lanes.  If you look at your view, you will notice a lane for open work items (which have not started), and In Progress work items (which are currently being worked on).  If you look closely, there is a horizontal slider at the bottom of this view, and you can scroll to the right and see a lane for completed items as well.  Make minor updates to the taskboard as you go, as long as it doesn’t impact the meeting.  You can drag and drop work items between the lanes, and you can update the attributes if needed.

During the standup meeting, members should be notifying others of their progress, what they plan to do next, and highlight any risks or impediments to their progress.    This not only makes every team member accountable to the team (who is going to stand up and say, “Today I am going to finalize my fantasy football lineup, and watch YouTube videos of kittens?“), it also helps team members to collaborate.  They can help each other with suggestions, short cuts, and help avoid known technical issues.  You want to foster a collaborative team environment, not a structured status reporting environment (filled with Scrum zombies).

Ending the sprint
As you get closer to the end of the sprint, most of your work items should be in the resolved column in your scrum board.  You should be seeing steady progress throughout the sprint.  Your sprint should end with a demonstration of running software that demonstrates the new functionality that has been implemented.  Once the stakeholders sign off on the implementation, your sprint is almost done.

At this point you should bring your team together and have a sprint retrospective.  Go out and create one more work item for your sprint (you should do this at the beginning of the sprint, so people don’t forget it at the end).  They type for the new work item should be “Retrospective”.  During the retrospective, the team should reflect on what they did well, what they struggled with, and what they can improve.  All of this information should be captured in the notes section of the Retrospective work item.  Once the retrospective is over, the Scrummaster may want to create some new work items to reflect things that the team can do in future sprints, that will improve overall team performance.

Often these retrospective observations will end up creating stories that do not serve an end user need, but instead that serve a development team need.  Some people have referred to this as technical debt, but there is some argument about how to best characterize this work.  Examples of stories coming from retrospectives may include the refactoring of portions of the code, development of automated testing scripts, implementation of build and delivery automation capabilities, and other related issues.  Often these “tech debt” stories are the ones that are pulled from the backlog when a team finishes their planned sprint work early, and is able to take on additional work within a sprint.

 Wrapping Up
At this point we’ve done a quick overview of how scrum teams can use IDS to help organize and track their sprint planning and execution, how they can groom their backlogs, and do planning in a transparent manner so all stakeholders and team members can have a shared understanding of the goals and the progress of the scrum team during a sprint.

In our next article, we’ll touch on some more intermediate topics.  We’ll talk about how to effectively use dashboards with IDS, effective ways to work with code in IDS, and some small tips and tricks that can help your teams use IDS to deliver end user results that will make your customers smile.