Certified Scrum Product Owner (CSPO)

Scrum_Product_Owner_Horiz1
Last month I attended a fantastic course to become a Certified Scrum Product Owner (CSPO) with the legendary Mike Cohn.

What are Product Owners?

To quote the Scrum Alliance:

“Certified Scrum Product Owners® have been taught the Scrum terminology, practices, and principles that enable them to fulfill the role of Product Owner on a Scrum team. CSPOs are typically the individuals who are closest to the “business side” of the project. They are charged by the organization to “get the product out” and are expected to do the best possible job of satisfying all the stakeholders. CSPOs maintain the product backlog and ensure that everyone knows the priorities.”

The course covered

  • Overview of Scrum
    • Scrum is empirical
    • The Scrum project community
  • Roles and Responsibilities
    • Team / ScrumMaster / Product Owner
    • Your role in the four Scrum meetings
    • Things that are not your job
  • Chartering the Project
    • Creating an “Igniting Purpose”
    • Five techniques
  • Estimating
    • Estimating the size of work
    • Planning Poker®
  • The Product Backlog
    • Emergent requirements
    • User stories on the product backlog
    • The product backlog iceberg
    • User stories in a formal contract
  • Sprints
    • What is potentially shippable?
    • Changes during the sprint
    • Sustainable pace & over commitment
    • Abnormal termination
  • Tracking Progress
    • Burndown charts
    • Taskboards
  • Prioritising
    • The proper level for prioritizing
    • Four factors to consider
    • Kano analysis
    • Theme screening and scoring
    • Relative weighting
  • Release Planning
    • Extrapolating end dates
    • Fixed-scope and fixed-price projects
  • Scaling the Product Owner
    • Sharing one product backlog
    • Visualizing a large product backlog
    • The scrum of scrums meeting
    • The chief product owner

Conclusions

I loved the course and would highly recommend it. I particularly found the session on Prioritisation one of the most valuable with the section on Kano Analysis being used in my recent presentation. I’ve also taken what I learnt in the Estimating session and delivered something internally with colleagues at Sigma to help the whole team to estimate better.

Developing an MVP that your users will love

Last week I was lucky enough to present again at Camp Digital, a two-day event run by Sigma UK full of inspirational seminars and workshops discussing user experience, exploring key trends in our industry and connecting people in our community.

It’s the second year that I’ve been invited to speak, after my presentation last year on Rapid Prototyping.

Synopsis

Minimum Viable Product (MVP) is a key lean startup concept popularised by Eric Ries to maximise validated learning for the least amount of effort expended. No-longer just a concept used in the lean startup world, defining MVPs has become a popular product development strategy for agile teams around the world. But what’s the impact of constantly focusing on delivering the ‘minimum’ and do your users ever truly love your product as a result.

In this session Jamie will look at how your team can develop an MVP that both meets your business requirements and keeps your users coming back for more.

Presentation

[slideshare id=32844736&doc=cddevelopinganmvpyouruserswilllove-140328043803-phpapp01]

Sigma Camp Digital 3D Shadows
Camp Digital – Manchester, UK

Camp Digital returns as a two-day programme of inspirational seminars and workshops discussing user experience, exploring key trends in our industry and connecting people in our community.

Why not check out some more presentations and videos here?

Using Analytics to Design for Devices

In my last post I discussed designing for Mobile First. But before you can start designing for mobile, it’s a good idea to have an understanding of how users are using mobiles and tablets to interact with your website and consume your content. Although it is true that overall mobile and tablet usage is on the rise, different industries are seeing different usage of these device.

device-dashboard_featured

Using this Dashboard Junkie dashboard as a base, I was able to create a dashboard that attempted to answer a number of key questions designers may be asking when starting a mobile first project:

  • Which breakpoints are most popular on my website
  • Which browsers are we designing for (and testing in)
  • What input methods are users using

Try adding it to your Google Analytics account and let me know how you get on.

Dashboard components

How many unique visitors?
Here you’ll see a count of how many different users (or computers/devices, really) that have visited your website.

How many unique smartphone visitors?
Here you’ll see how many of your visitors are using a smartphone or tablet to interact with your website and consume your content.

How many unique laptop/desktop visitors?
This widget counts the number of visitors that didn’t use a tablet or smartphone to view your website content.

Just below the large figure you will see a percentage that tells you how this number compares to the total number of visitors.

Visitors’ mobile/tablet brands – Top 3
A pie chart that displays the top 3 smartphone/tablet brands used among your audience.

Visitors’ favorite (mobile) devices – Top 5
This widget tells you exact brand and model of your mobile visitors.

Only smartphones/tablets will relay their brand and model information to Google Analytics.

Laptops/desktop cannot be identified in such detail.

Tip: Click on the photo/camera icon and you will see one or more pictures of the hardware device in question.

Visitors’ screen resolutions – Top 10
Here you can check out the display resolution (measured in Pixels) of your visitors. This information can be very useful when making decisions about where to place your breakpoints.

Visitors’ favorite browsers
Here you can see the most popular browsers that users are using to view your website. This will help you to identify which browsers to prioritise testing on.

Visitors’ dwell time by device
Here you can see the average page view time by each device category. This information can be helpful to understand which devices users use when completing certain tasks on your website.

Visitors’ mobile inputs selectors – Top 5
Here you can see the input methods users use to interact with your website. You can use the information to make decisions about how to layout your navigation, input fields and button sizes.

Visitors mobile OS – Top 5
Here you can see the most popular operating systems used by your visitors. This information can be really helpful if you’re considering developing a mobile app and you want to know which platform to prioritise first.

Axure goes Mobile First

ResponsiveImage-01 I’ve been playing with some of the latest Axure 7 features recently and one of my favourites is the new Adaptive Views feature. Adaptive Views define the breakpoints where you want your pages to switch to a different layout or style. This allows you to prototype in a way that forces you to consider your mobile and tablet experience. Former Yahoo! design architect Luke Wroblewski, coined the expression Mobile First to describe the process of designing websites and other software for the mobile first, rather than last (as can often happen).

Why’s it important?

While responsive web design is not entirely new, designers and developers have often struggled to demonstrate how a responsive site will look on different devices, prior to build. The options are usually to design up every view individually or to prototype in HTML & CSS. The former option often lacks any detail of how interaction will take place, whereas the latter often focuses too heavily on technical implementation and can sometimes overlook visual treatment and design aesthetics.

Designing for mobile first 1:

  • Prepares you for the explosive growth and new opportunities emerging on mobile today
  • Forces you to focus and prioritise your products by embracing the constraints inherent in mobile design
  • Allows you to deliver innovative experiences by building on new capabilities native to mobile devices and modes of use.

Axure allows UX and interaction designers to prototype with both realistic interactions and visual treatment. The outcome is a realistic representation of your website or application in a range of views, for different devices.

How it works

Adaptive views are based on browser/device width and/or height. Axure has a range of mobile and tablet dimensions (in both landscape and portrait orientation) predefined out of the box. Views inherit from one another so a change to the location, size, or style of a widget in the parent view affects its children, but a change in the child view does not affect the parent.

Editing a widget’s text, interactions, and other widget properties affects the widget in all views. The widget is the same widget across views (not a copy) so you only have to update the property once.

While most of the tutorials show desktop being created as the base view that all other views inherit from, I would encourage you to consider using the 320px width mobile portrait view as your base and inheriting up through the spectrum until you reach desktop. This will make your prototype truly mobile first and force you to consider interactions and behaviours that may get overlooked if you settle for a more traditional approach.

The prototype switches views based on the browser size or can be manipulated using the adaptive view icon in the left hand sitemap. I have hosted the Axure Learn example here.

What I’ve discovered

If you have been using Axure prior to version 7’s release this new feature shouldn’t take you too long to get to grips with. It is possibly quite advanced for novice users of Axure, but everyone has to start somewhere.

I noticed a significant performance drop in Axure when using a number of images and widgets across multiple views. I am hoping that future updates to Axure 7 will improve this.

Out of the box Axure doesn’t add a viewport tag like this to its HTML generated prototypes:

<meta name="viewport" content="width=device-width"> 

In order to configure this navigate to: Publish > More Generators & Configurations… > HTML > Mobile/Device and tick Include Viewport Tag.

Mobile first by Luke Wroblewski

For more on Mobile First check out Luke Wroblewski’s book.

Need help with your next prototype project? Why not get in touch.

[1] Katie Messner. Sep 30, 2013. “Mobile Gov Wiki.” [online]. mobilegovwiki.howto.gov

Kanban: Optimising for predictability – presentation

In the next couple of weeks I’ll be presenting at a ‘Lightning Lunch’ at Sigma UK on Kanban and how you can optimise the flow of tiny tasks (stories) to make predictable deliverables. This presentation is based on a blog post I wrote some time ago on the same subject.

I’m currently working on a very large Scrum programme that uses a board very similar to a Kanban board, however, we’re not enforcing WIP limits and we only ship things once a sprint. While this in itself feels very fast and very agile to some, it’s not without risks and sometimes feels a little ‘big bang’ release due to the amount of code that is getting delivered in a single sprint. This got me thinking about the continuous test and deployment cycles within Kanban teams as a potential enhancement to our current process.

Kanban doesn’t pretend to solve the problems, but it does allow teams to focus on continuous delivery and continuous improvement. It encourages teams to work as a multi-disciplinary unit rather than as a collection of silos and functions.

I should say that I have only ever done this ‘agency-side’ and as a result commercial constraints sometimes limit our ability to apply too aggressive WIP limits. I’d be really interested in hearing from anyone who has experience of running Kanban projects for multiple customers within a software/design agency. I’m sure there is some additional tweeks to help the implementation.

Prototyping your processes diagrams

This week I heard a fantastic podcast over at TheBACoach.com about writing high value user stories through structured conversations. In it Ellen Gottesdiener and Mary Gorman, authors of Discover to Deliver, suggested collaboratively working on process diagrams with your customers. In fact, they suggested encouraging stakeholders to break the diagrams!

The idea got me pretty excited about a project I’m currently working on and some workshops I had coming up. Although I’m pretty confident at diagramming as a requirements specification technique and have studied UML, BPMN and database modelling techniques, I rarely use them for elicitation purposes. And I have to say, however confident I am with the practice, I’m always worried that a stakeholder will spot the bit I’ve missed or will mention an edge-case that I didn’t identify. But Ellen and Mary were suggesting a completely different approach – hold your hands up and say it’s not finished, that it needs some polish and it needs input to be completed and allow your stakeholders to roll their sleeves up and participate in the drawing of your process diagrams.

Something similar to the finished product. Basic, bare even, but full of meaning to the team who helped craft it.

So that’s exactly what I did, I thought back to some of my experiences of prototyping wireframes and some of the lessons learnt are very transferable. Mainly, if the prototype looks polished stakeholders will think it’s finished (and will often be far more critical). So, we used paper and pens to draw out a basic process flow, there were no swimlanes or beautiful straight lines that a tool would give you, but it was there, a vehicle for some structured conversation.

I put it on the table with some other pens and watched as the team looked at it, quite shocked at how bare it was (probably questioning my fee…) but straight away people started drawing on the missing elements. And then they took it further, “this bit is only happens if X is true” and “We want to be able to delay a step, in fact we’d like to be able to delay two of the steps.”

We were prototyping a process flow, well they were and I was taking the notes from all the business logic and constraints that were being discussed. And because I wasn’t holding the pen and doing all the work I was able to sit back and facilitate the discussion and prototyping, dipping into the 7 Product Dimensions [pdf], that I also learnt about on the podcast, ensuring that we had covered where the ‘data’ was coming from for an aspect of the diagram or what the ‘control’ was around another.

Now I was lucky, the team I was working with are pretty technical. In fact they are a mix of subject matter experts and other analysts, which made the job a bit easier. But even if your team aren’t expert diagram drawers, with your help they’ll be able to articulate enough to help you draw something that they can validate. Constantly ask questions like:

  • Is this right?
  • Is there anything that happens after this step?
  • Is there anything missing that you can see?

Working with your stakeholders in this way will help them to feel empowered in the delivery of your project, it helps develop rapport between the team and will pay dividends over the lifetime of the project.

Annotating wireframes for delivery: the agile way

I usually try and keep these posts technology agnostic, but when it comes to wireframing it has to be said that I’m an Axure fanboy. I know there are lots of other great tools out there but this is the one that I’ve settled on.

Axure has a built-in specification generator, which reminds me of projects where the quality of my deliverables were measured by the length of the documents. However, I’ve been playing with some of these settings in order to turn the built-in features into something a bit more useful. Here’s what I discovered:

The Annotations Widget

This is the Annotations panel within the Widget Properties Pane (you can open it using ctrl+1). By default it has lots of options, covering a range of needs from the features status, risk, owner and benefit etc. While this is all very useful it can feel a bit overwhelming if you don’t know all that information or feel like you’re duplicating effort by repeating info that is already being captured against your user stories. To help me capture what I need, without writing war and peace, I’ve opted for the following fields:

axure widget properties
An example of the annotation properties with Axure 6.5

<dl>

Description
I use this field to describe what the feature is, nothing fancy. “This is a drop down picker that allows a user to select their timezone”.
OnClick
This field describes what the user can expect to happen when they interact/click on the feature. “Onclick the user will be presented with a list of timezones to select from. By default ‘GMT London’ should be selected”.
Design Logic
I use this field to describe when the feature will be shown and any edge cases where the design or layout may change. “The first time the user uses the application they should set their timezone. On returning to the application this should already be set and display the option the user has stored previously in their preferences”.

dynamic notesOn generating the prototype it builds into HTML and adds a small iconnote over the top right hand corner of the feature. If you hover over them your cursor will change to have a ‘?’.

When you click on the note it will open up and can be moved around the page, in order to prevent it to obscure the feature it is describing.

You can play around with combinations of fields that you use and even have different ones saved for different clients. Any fields that are left blank when annotating your prototype will not be shown once the HTML is generated.

Sharing Axure Files

If you’ve not seen it yet I strongly recommend Axure Share. It allows you to store and share your Axure prototypes and even has functionality to allow users to discuss elements on the prototype.

Read More…

If you want to find out more about the Axure annotations feature why not check out the following: