Meet me at 4developers conference!

15 03 2014

Warsaw, 7th of April 2014, the 4developers conference will take place. Last year edition was full of outstanding speeches and workshops, therefore I am really honored to be the speaker in this year’s edition!


Together with Łukasz Roth, who inspired and initiated our talk, we’ll be talking about the way how the interaction designer can collaborate with software developers within the Scrum team to build impressive app that meets user’s needs, is good looking and developed in an Agile way.

I am really excited to take part in this event with Łukasz as the speakers, as well as to be the auditor on other sessions and meet all those people attending the event!

JIRA & GreenHopper starter tutorials

17 08 2013

I found two very useful short screencasts presenting how to use GreenHopper in JIRA. These show the full Scrum workflow: Plan – Work – Report. This is a good starter introduction, however adjusting and configuring JIRA according to your needs may be required. To get started, firstly watch the videos below.

This video has short theoretical introduction, then Demo and after that Q&A session. If you’re not interested in Introduction, just skip to demo (7 min). Demo lasts only about 15 minutes.

The second screencast is quite similar, however, if you feel that you are not enough with GreenHopper then it is also definetely good to watch it:

Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality

Donate Button with Credit Cards

Thank You!

Scrum User Stories

31 03 2012

First thing that should be done before Scrum project launch is defining user stories. These can be compared to well known use cases, however they are not the same. This article is worth reading first, if You are new with Scrum.

Use Case versus User Story

Use case is general term specifying area in which product will be used. For example a car can be used in one case in company for a salesman transportation tool or – in another case – at home in family’s every day life. Wiki article section describes in simple manner.
User stories defines details of certain use case from the users point of view. They are based on the following template:

As a <product user> I want <what> so that <users benefit>

The goal is to look at the product from the users perspective and deliver products that suits their needs. Sample user story may look like:

As a salesman I want car to be equipped with GPS so that I can easily set my direction”

You can define as much user stories as You wish – it depends on project complexity.

I. N. V. E. S. T. in User stories

Well prepared user stories should follow the INVEST idea. Its theory is well described here (begin with slide 12). Further in text You will find some practical clues.

User story should fit sprint

The biggest user story should be small enough to implement it during one sprint. It is possible to build small stories although it requires a bit of work. During sprint itself the user story can be divided into small tasks and distributed in self organizing team.

Definition of done

Each user story needs a criteria of completeness. This is the moment when nothing more has to be done to fulfil it (for example: salesman can reach his goal thanks to GPS in his car). The team should implement functionality having definition of done in mind. Team should not be predictive and add new things that overrides the done definition. These will be added in next user stories.

User story’s complexity and priority

Priority depends on business requirements and/or technical constraints and probably there will be no problem with defining it.

Complexity is a bit more difficult to evaluate. This process begins with assessment of one user story that is easiest to estimate (basing on team experience). The latter user stories are compared to stories already assessed. Team decides if tasks connected with it are more complex or not, and how much. It is easier to compare unknown task to the known one and assess it, than assess unknown task from scratch.

Complexity unit

There is no complexity unit :) You just give it some value without a unit. Nor days neither hours are used. If user story has complexity 8, and another one seems to be much more complex You give it complexity 40. There is no need to measure it in days or hours. You just see that one task is 5 times more complex than another.

Planning poker

Complexity values, given to the user stories, are taken from the Planning Poker subset:

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (unknown)

It is easy to define complexity accurately if it is small. If it is bigger – it is difficult and not needed. It makes sense to say that something is 1,5 meter long in opposite to say that something is 1000,5 meters long. This 0,5 meter is not significant in latter case.
Planning poker has simple rules: each team member chooses one card from his set and estimates task on his own. Then each member shows his card and agree on complexity value after short discussion.

Product backlog is a set of user stories

Functionalities that come from user stories should be put in a product backlog. They should be ordered according to priorities and have complexity assessed. Team chooses user stories that will be handled in upcoming sprint.

Common mistakes

User stories are written for user (not for Product Owner, Developer or anyone else). Each user story corresponds to benefit to user. Read some valuable clues here.

Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality

Donate Button with Credit Cards

Thank You!

Improving team communication with Scrum

21 01 2012

Scrum is a framework (a set of rules) that can improve (software) creation process in area of project management. It introduces rules, the team has to follow. These rules makes sense for me, this is why I think this is worth sharing.
Way of thinking introduced by Scrum is valuable not only in IT but also in other areas, including everyday life (although it is not as simple as IT). Here is a Scrum Guide that is short and simple – worth reading.

Scrum uses short steps
The idea is to implement new functionalities and have potentially shippable product at the end of each step (working demo). Step should last no longer than 4 weeks and is called Sprint. Each Sprint aims to implement chosen functionalities listed in a Project Backlog – a list of tasks required in a project with priority and complexity for each of them.

Scrum is agile.
It means that it follows the Agile manifest and allows project team to dynamically change the scope of project according to the market and/or customer requirements. After each Sprint,the product backlog is adjusted, so the priorities or tasks can be changed. This is extremely important in R&Ds where reacting on a market changes is crucial.

Scrum improves communication.
Scrum requires a set of meetings to be scheduled. Before each Sprint there is a sprint planning meeting, that should last for about 8 hours for a 4 weeks long sprint. At the end or sprint the sprint summary meeting shall be held.
However the best part of scrum methodology are daily scrums – 15 minutes long meetings held everyday by a project team. Each of team member answers shortly three questions:
1. What he did yesterday?
2. What is he going to do today?
3. Are there any obstacles that interrupts his work?
Thanks to daily scrum, the whole team is aware of status and tasks in progress all the time, is able to react fast to remove obstacles as they appear and adjust working pace. And last, but not least – they can provide and receive feedback from other team members.

Planning sprint
How much the team can do during a sprint? It is assesed basing on historical sprints achievements. Amount of work (which relates to task complexity in a project backlog) is measured in a unitless unit :) Let’s say that the team handled to do 15 units during last sprint. Then probably it is able to do the same in future sprints.

How to assess task complexity?
By measuring the task You already know how complex is (for example 5 units) and comparing it to the new task. Then You have to say something like ‘this task is more complex, so its complexity would be 10 units’. Scrum is about basing on a history and experience.

Scrum roles
Are very well defined and described in a Scrum Guide. Thanks to separation of duties the Scrum can succeed – this is crucial.

You have to trust your team members. It is easy to fail if You believe that the scrum is introduced just to control You and check how do You perform. If You think so, then probably You don’t trust in Your team’s good will or Your team truly doesn’t have a good will, which is the worse case.

‘introducing Scrum requires fighting with company’s resistance’. I don’t believe it :) why the company would resist? Just be optimistic.

Scrum is most effective only when fully implemented. However taking only the best parts from it is also an improvement. In my opinion such parts are Daily Scrums and way the task complexity is assessed. Best part of scrum is fostering communication and fast reaction on market changes. These makes it surely worth trying.

Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality

Donate Button with Credit Cards

Thank You!

%d bloggers like this: