Prioritizing a backlog with multi-attribute utility analysis (MAUA)

One of the most important things a product owner should do is to prioritize. What should we do now? Where should we put all our efforts, money and brains?. Inside a product team there are internal and external inputs that vary from opportunities, experiments and outcomes to risks, debts or defects. While different sub-teams can come up with a number of features or stories that come out of specific artefacts like dependency graphs, user story maps or metric optimization items, with enough amount of inputs the putting-all-together backlog can be hard to prioritize. If I have framed your situation please keep reading.

Read more →

 

Work in progress (WIP) in Scrum

Let me tell you a story, about how important is focus (a core value of Scrum) and how work in progress (WIP) affects it. Two scrum teams were working once. Team A and team B. All were motivated, good, smart, had equally good product owner with equally INVEST user stories.
They both want to do a great work, while enjoying, providing their expertise, growing together, a dream made true

The first day of the sprint team A did a nice daily where everyone knew what the priority was. Started targeting the most important user stories. Story 1 for instance. At first there were some dependencies, like api calls, designs, whatever, but it doesn’t matter team A worked as much as they could in the first story 1 using mockup objects, building dummy screens, faking apis and so on. Whenever a dependency is met, the team integrates or team can analyse and changes follow just-in-time. After a working day, they had story 1 ready to integrate, the most important ready to send to QA. They did send that to QA and went for a coffee. QA found out misunderstandings so went back to the team to reopen story 1 with feedback. The misunderstanding was no big deal so they fixed it and sent it to QA. QA found bugs, so the story one was reopened. Luckily they had now a couple of automated tests (sadly they were not using TDD). Every one was in the right branch, every one had the editor opened, a couple of hours of pair programming fixed all the bugs. It took too much time to close story 1, double of what was estimated but finally was merged. The kept on with next most important story, same way, trying to close it effectively without bugs. Meantime QA was automating story 1. As a result after the sprint, only 50% of the sprint backlog was finished and released to production. The other stories along with some new important ones went to the next sprint.

Team B on the other hand opened 2 stories, story 1 and story 2. Started working on both. While some dependency kicked they would change branch and context. The dependencies doubled, because now we need two designs and two apis, as usual handing out an api or design leads to more questions, changes, feedback loop… at some point both stories were sent to QA. QA was a bit of a bottleneck for a few minutes. Just after sending the stories to QA, the team opened other two stories, 3, 4 in new branches and started working. Shortly after, QA found out errors related to the interpretation of the QA in story 1. Reported back, but everyone was busy so QA wrote that on a document. Regarding the team, some kept on working in the new stories, some other reopened the old stories and started changing branch and working. The other story was ok regarding acceptance criteria but had bugs, reported. By then there were four stories, a document for the bugs, four branches and a lot of stressed developers seeing that the time was running. The end of the sprint the general mood was horrible. Team was working overtime, stressed, PO worried and losing trust, QA was upset and the final outcome of the sprint was a high number of buggy stuff the PO was unsure to deploy. The PO planned a “re-do” sprint taking the bugs as reference, sprint retrospective was a war, as frustrating as the sprint review.

Who will be fitter, happier, more productive in the long term? And I am not talking about limiting the work in progress to one story, it is an example

What happened to the team of case B? At first it seemed they were going “faster” -the illusion of productivity– but their path was unsustainable. Shortly after they were eaten by doubts. By mid sprint the chaos was total, nobody was sure of the status of the stories or what to do about them to complete them. This is a consequence of a low focus

Some causes and effects of a low focus (yes a core value!) with lots of context change

– Development overhead, change branch, scheme, etc
– Documents had to be read, controlled, maintained
– Horizontal dependencies were flooded (and blamed)
– QA was not focused so missed important stuff
– Feeling of doing over and over the same things (second sprint)
– At the beginning of sprint, apparently working faster that estimated
– Shortly after beginning, working much slower
– End of sprint, stressful madness
– For the product, no real increment until the sprint were they fixed all the bugs
– No possibility to react to changes
– Bad team building, hard retrospective, effects of the failure feeling
– Lack of confidence for next sprints
– Stress/mood/blaming/excuses
– A lot of horizontal slicing while vertical slicing is the value
– Working more to get worse results

 

Testing with zombie and jasmine for nodejs

zombie-appAn interesting choice for performing acceptance tests for your web application can be the use of a headless browser.

You could model your acceptance tests directly from for instance your scrum user stories’ how to demo. That can be achieved through the use of a behaviour-driven testing framework. I have created an example with the use of jasmine and zombie

Read more →

 

Database migrations with node db-migrate

To continue with the research on database migrations started with the post about liquibase I will provide a small tutorial for node’s db-migrate on how to database migrations with node db-migrate

I am much more used to this kind of tool in which the developer’s responsibility of providing migrations is done in the same language of development. The fundamentals are the same. It seems to me that liquibase can be a bit more powerful when handling severe branching, but the simplicity of these kind of framework tools makes them desirable

I will use the same schema and setup as on the previous post, please check it out there on the post about liquibase

Read more →

 

Managing database schema changes with liquibase on an existing database tutorial

If you have had a project with several developers working at a high velocity on different branches you are probably aware of the amount of trouble that a theoretically simple task such as managing the db schema changes can provoke. The main issues occur on a daily-basis at development, less DRY, less agile; also the production deployments and merges can be severly affected

Database migration tools

Luckily most frameworks come with migration tools, rails, django, sequelize or yii as it is an important tool to ensure some agility. Today I will be taking a look at liquibase which you may find interesting

Read more →

 

Dividing scrum user stories into dummy tasks is evil

One of the keypoints of the scrum sprint planning meeting is the division of the user stories into tasks

  • it leaves less questions unclear to anyone, by dividing you find out more about the task
  • it helps provide better estimations
  • it gives all the team the same understanding of the user story scope, affecting at the sprint scope
  • it allows a better parallel work to happen, particularly on highly vertically specialized teams
  • team does it, team adapts it to the way to work (TDD, design mockups…)
  • the stories come up with their own roadmap which also serves as feedback for the PO
  • … I could add more stuff here

At the same time sprint planning meetings are considered a nightmare by some teams (quite hard yep). Earlier than later someone comes up with some sort of copy & paste candidate of a generic list of tasks as a solution to make the meeting lighter, for example

Read more →

 

A script for running an erlang application as a service on a user

As a newbie erlanger I had to deploy my first application into production some time ago. Also it had to be run by a specific user. I am way too far from knowing what there is to know about erlang releases, so I have come up with some quick solution in the meantime. Maybe you beginner can also find it useful

The first element is a shell script. I am using it for running several application instances with different names, hence the second parameter in Usage: $0 {start|stop|debug} appname. I think you can easily grab the idea behind it and apply that to your own application

Read more →

 

CSRF in django rest_framework

I am very much into connecting different front-ends (angularjs, javascript, titanium appcelerator, and so on…) to a rest back-end as you may have seen on previous articles. This made me aware of problems with django’s CSRF protection, yet another developer hiccup

What is CSRF?

CSRF, standing for cross-site request forgery is a kind of attack in which a malicious web site cheats a user to perform actions on some other web site where the user may be authenticated (some evil purposes included). This is achieved by placing forms or links to the site where the user is logged in. Most systems nowadays are including protection against this kind of attack by ensuring that the form that performs the action is only present in your site. This is achieved by setting a server side known token into the form (as an alternative for a referral based system that could be spoofed).

For those interested in a more detailed explanation check csrf protection on the security tips for web developers

Well as for now, as django rest_framework with session based authentication includes csrf and since I haven’t manage to get the csrf_exempt decorator in my rest_framework class based views, I have added this token to the login/signup response of my auth api

Read more →

 

Mobile facebook application with django allauth sign up

These past weeks I have been investigating some technologies for a titanium client-server mobile social application with a rest backend. I have come up with a nice config for django with allauth and the rest_framework, all used without too much work form the titanium side. Here are my findings on the subject for a titanium alloy mobile facebook application with django allauth for sign up

The first issue I have come across is the huge amount of user related functionality I should code. Well, no!! With allauth I only had to code a simple function that acts as interface for the login and for the sign-up.

Bear with me as this is still work in progress and I will be providing only some code sketches, but anybody in this situation can follow my steps here.

In django I have installed and setup the django-allauth wonderful plugin. Really this does almost anything you may need, and what it does not it is easily doable by extending its views and templates. Actually you can download all the templates

Read more →

 

Google maps rails crud sample application (I), creating a marker and saving its data in the database

OPEN On a previous post I mentioned something about . I have finally put together a database driven google maps CRUD demo (because crud is the new hello world!)

This demo rails app (called playgrounds) is written for Rails 4 (ruby 2.0.0) with gmaps4rails and you have the full code available for you to play with as usual. Its main purpose is to allow any user to store and modify spots on the map containing sport playgrounds (one per marker). I Tried to make this demo as good in terms of teaching how the thing works as possible as well as KISS This is the first post, covering the ‘C’ of the CRUD

Read more →