Characteristics of good product backlog

Piotr Romanowski

Backlog_post

 

Without a shadow of a doubt, a product backlog is one of the most important things when we talk about an agile way of software development. Backlog is a place where all your product requirements should be stored. These requirements are called PBI – Product Backlog Items.

Backlog is also a tool that can help your team with proper planning. Its aim is to:
- facilitate your team with delivering the greatest value possible
- ease workflow and track work progress

 

In this post, we would like to devote our attention to product backlog. What are the good product backlog features and how to use them.
Ok, sit comfortably in your chair and let’s walk through the world of agile product backlog! Enjoy the read!

 

1. A good product backlog is ORDERED
Simply speaking – the items are arranged in order of execution.

Priority is significant here, which means that two different items cannot be equal with regards to importance – one needs to be precede the other (closer to the top of the backlog).
Backlog is also the only place where requirements are stored. Therefore, before we place any new requirement we must fully consider its value and importance.

 

A product owner is a person responsible for arranging the backlog and putting the items in the right order. Product owner should aim at stacking the requirements on the backlog, so that with every iteration a new version of software can be delivered.

We should keep one thing in mind when we talk about product backlog. It can be organized in a variety of ways – everything depends on the context!

 

 

2. A good product backlog is RELEVANT
Contains items relevant to the current requirements and needs.

A brilliant and very useful benefit of the agile way of software development is that it allows us to constantly check whether our product corresponds with the expectations. If not, we can just adjust it or change it (with regards to the Inspect&Adapt rule). It’s as simple as that :)

 

 

3. A good product backlog is TRANSPARENT
It’s visible and legible to all those parties involved.

Backlog can be adjusted when needed. However, it can only be done easily when it’s transparent and all interested people can get acquainted with it and understand it well.
It’s way easier to talk about some items and their importance with product owner (and maybe convince him to move our awesome feature to the top) when it’s clear and legible.

It’s absolutely great when a backlog item has a format of a user story:

As a [role] I want [a goal], so that [benefit]

This format not only facilitates the creation of requirements that are intuitively understandable for all concerned but also it tends to think in terms of the users needs.

 

 

4. A good product backlog is REFINED
The level of detail is adapted to the requirements of its position in the backlog.

A refined product backlog is one where requirements are adequately sized up to their position. Moreover, all requirements on top should be clear and well understood and ready to planned on.

This characteristic can save us a lot of time and unnecessary effort. Because of that, we can avoid a situation where we see huge, vague requirement on top of our backlog, where the team spent lots of time analyzing it before starting a new iteration.

Good product backlog should have a pyramid structure – a number of very small (decomposed) requirements on top, increasing requirements somewhere in the middle and keeping large, general ideas on the very bottom.
It’s rather obvious that those requirements that are on the top should be small enough to be performed in next sprint.

 

 

One more thing…
There are many ways to manage requirements and backlogs, it depends on various factors like product type or product lifecycle. A lesson that we need to learn is that we should stay flexible and open when thinking about choosing the right way, relevant to our needs.

 

PS. You can easily arrange your winning backlog with the above mentioned rules and characteristics by using our tinyPM. Check out all our awesome features here - including backlog management.

Why agile coaching matters?

Piotr Romanowski

7 

“Coaching is the universal language of change and learning.” – CNN

 

In our previous post, we’ve provided you with some hints on how to build a good agile team that will work like a well-oiled machine. We agreed that building a team isn’t very easy, but it’s still feasible and necessary in order to achieve extraordinary results.

As a matter of fact, pulling people together and maintaining the team in a good spirit can be even harder. This is the time when agile coaching can give us a helping hand.

 

Anthony Robins (famous life coach) coined a term CANI –  which is an acronym for Constant And Neverending Improvement.  The key word here is an improvement. Therefore, we cannot say that agile is yet another process – an agile approach is a means of improving everything – c o n s t a n t l y.

 

Here we have a space for agile coach that can help the team to understand why, what they’re doing really matters, and why the agile way matters.

But what is an Agile Coaching, anyhow?

 

Agile coaching competency framework
Agile coach should aim to “grow a productive Agile team that thinks for itself rather than relying on you to lay down the agile law”.*

As we can see it’s not about simply showing the right path but rather helping the team to find their own way within an agile environment.

 

We can boil down the agile coaching to five elements:

Mentoring – a coach is a helping hand that can provide the team with necessary advice when it’s needed. It’s quite critical for a coach to have a wide range of knowledge and experience not only in the scrum methodology. Moreover, agile coach needs to lead by example, simply walk the walk, so to speak. So if a coach wants to teach about agile principles,  he needs to follow the agile rules himself during daily work.

Training – agile coach needs to pass all necessary knowledge and enforce it into practice. It’s not a rocket science, every team is different, made up of various people with different experiences and abilities in acquiring knowledge. That’s why a coach needs to remember to adjust the form of information flow to a particular team.

Management – however not managing people but managing the process itself. As we have agreed – agile is a process of constant improvement.

Coaching – it’s a partnership process, during which a coach supports the client (can be a group or a team) in making the best use of his potential in order to achieve particular goals. How does it get done? By asking proper questions, by understanding the team’s flow and all the habits that come with daily work. A coach should help his client transform to the point where he wants to be.

Assistance – coach needs to facilitate with solving all the issues that will occur somewhere along the line with all his experience and knowledge.

 

Well, considering the above fact it seems that being agile coach is not a piece of cake. But who said it’s going to be easy anyway? :)

It appears that the hardest part in becoming a good, agile coach is developing all of the earlier mentioned competencies. Agile coach needs to have a wide range of knowledge as well as skills to perform all those roles.

 

 

So what skills are important to be developed for agile coaches? As Rachel Davies wrote:

- Working with people: listening, giving feedback, asking questions, building trust and rapport

- Facilitating change: enlisting support, reaching agreement, spreading success, learning from failure

- Systems thinking: seeing the bigger picture, identifying levers for change, communicating danger signals

 

Benefits from agile coaching

Implementing scrum in an organization is often perceived as a remedy for all the problems that a company suffers from. But (as you may have experienced in your companies) implementing scrum isn’t a very easy task and can entail a lot of other problems.

That’s why agile coach is a must!

 

So here we have some of the benefits that a company can get from implementing an agile coaching:

- An outside view – coaches bring a new perspective to the organization, team and individuals and they remove intrinsic bias and interpersonal issues.

- New opportunity for improvement – a good coach provides learning and training for the employees and develops their skills

- Facing the problems – agile coaching creates an environment that allows teams to face the difficulties and work on a proper solution instead of sweeping problem under the table.

- Saving time and money – coaches bring both the tried and the new practices and processes to a team and organization, reducing the degree of trial and error commonly found in homegrown experimentations.

 

One size doesn’t fit all…

Just remember that agile coaching is not a holy grail for all the problems that you might encounter with your team.

“Every technique is working and is not working at the same time”

which means that a technique or a solution that was used for one team can work and, on the other hand, can be useless for another team. It’s all about the context and about people.

 

Picture (with small changes) courtesy of Brain vector designed by Freepik

Building an Agile Team

Piotr Romanowski

teamowrk_post

“Teamwork is the secret that make common people achieve an uncommon result.”
Ifeanyi Enoch Onuoha

 

While working in an agile environment teamwork is a must. As we mentioned in our previous post, almost all software projects are collaborative projects. This is how it works – for instance, if a team doesn’t pull together, people get frustrated. As a result (without a shadow of a doubt) the software they produce will reflect this.

We need to remember about an agile approach that indicates simplicity – it’s all about people and communication. The team needs to use proper tools, be well-managed and last but not least – need to know how to communicate properly. Moreover, in order to achieve uncommon results all team members need to not only work in an efficient way but also need to be a good, strong team that is based on mutual trust.

We can’t forget about yet another very important factor – the team work environment should facilitate an opportunity to develop a team spirit.

So how to build an agile team? For sure, you won’t be surprised if I’ll tell you that it’s not a simple question :)

Anyhow, despite the fact that it can be a really tough task, we can still follow some rules that can help us with creating a good team, that runs like a well-oiled machine. Thankfully, we have some hints for you!

 

 

1. Create opportunities and space
In an agile environment meetings like daily stand-ups or retrospectives are a great occasion for people to get to know each other better. Of course, probably the best way to do that is to arrange an integration meeting somewhere outside the company. This will provide, so to speak, a less formal way to pull the team together :) People will share their stories, hobbies and so forth. As the people on the team hear the stories, they get a better insight into a teammate. It may sound like a truism, but it really works!

In “Overcoming the Five Dysfunctions of a Team” Patrick Lencioni proposes a simple, yet very interesting exercise. During a meeting, each team member tells a story about a challenge that they faced in the past. Of course the leader or responsible person that runs this meeting should take care that everybody feels comfortable enough and assure that nobody is forced to share something that is too personal. The aim of such activity is to practice being open with teammates. This creates an opportunity to grow a mutual understanding and empathy.

Why not think about other ways to create a social glue among the team? Have you heard about the principle of work in one room? The whole team tremendously improves communication and makes many previous procedures become unnecessary.

That’s why it’s important for the team to adopt their own space in their specific way. Open space is a really good idea because it’s hard to build an Agile team when people are segregated (like testers are in one room, developers in another etc.). Although there are roles in the team, there is no such thing as a hierarchy.

In an agile way, we can speak about the “whole-team” approach. Such an approach stresses the importance of the team – “all hands on board”! The whole team is focused on delivering high-quality software. This kind of approach entails constant collaboration and communication among the people. Work in one room creates a lot of opportunities to make things happen!

And what if the team (for many reasons) can’t seat in the same place? Well, we will cover this topic later on. So keep on reading :)

 

Here we go with another idea – why not to think about having lunch together? As Liz Sedley wrote:

“Eat lunch with the team whenever you can. Listening to the team in an informal setting helps you understand team better. You’ll find teams often talk about the problems they’re facing over lunch – in a way they wouldn’t at a retrospective. (…)”

 

 

2. Have specified goals
Tony Robins said that “Setting goals is the first step in turning the invisible into the visible”. Spot on Tony! Once we have a great, motivated people we’ll need to set reachable but still challenging goals that give a sense of direction to the team.

This part can also be a tricky one. It goes without saying, that if we set too easy goals to achieve, the whole team will get bored and most probably demotivated soon. However, on the other hand, if objectives will be unattainable and out of reach it can paralyze everybody. That’s not what we want to achieve right?

The key thing is to create goals with accordance to the following rule: Not Too Easy, Not Too Hard. People like to be proud of their work so keep on setting challenging objectives. Let’s focus on building the environment where a team can demonstrate creativity, ingenuity, and team spirit to resolve problems in their own, agile way.

The big goal or the big picture is to create valuable and great software. But what does it mean to set goals in an agile way whatsoever? It’s all about the context!
You’ve probably heard about the SMART rule, haven’t you? It says that goals should be Specific, Measurable, Attainable, Realistic, and Timely.  So it’s a great rule, but sometimes it’s not very sufficient. Keeping in mind that agile is about being flexible and adjusting to a current situation (can be changed if needed) we can use SMART rule and adjust it to our agile approach.

 

S - Specific:
What do we want to achieve, How do we want to achieve it and Why do you want to achieve it?

- Measurable:
What cannot be measured cannot be managed. How will you know that you’ve reached your goal?

 

A - Attainable:
The goal should be challenging and encouraging for you to do the hard work.

 

R - Realistic:
Although the goal should be challenging, it should also be realistic.

 

- Timely:
When will we achieve this goal?

With regards to what was written before – we can use the SMART rule only when we become aware of the context. What does it mean? It means that sometimes we will have to pick a few criteria that will be important to our current situation. Let’s write it again:
- it’s all about  b e i n g  f l e x i b l e !

Agile goals can easily be modified if need be – changed resources, budget, energy or time.

 

3. Choose the right tool
Working with a proper tool that meets team expectations is a very important factor. The team should also have some space to explore the new technology and to experiment with new software and solutions that can make daily work much more effective.

A good old team-board helps to keep important things visible and it’s still widely used among a lot of companies. It’s ok to work with a board, but it’s not sufficient. Do we have an easy and quick access to the history of changes using a board? Nope. Can everyone involved in the project can look on the taskboard or backlog from any place any time? Nope.

Nowadays it’s pretty common that people can work in distributed teams all over the world – working remotely. Nonetheless, such teams still have a lot of successes! How do they do that? By using proper tools.

So, as you can see a traditional board that hangs somewhere on the wall in a team room may still leave a lot to be desired. Therefore, the key is to use a smart, agile collaboration tool that is reliable, clearly designed and easy to use. That’s why we’ve created tinyPM:

Lightweight and smart agile collaboration tool with product management, backlog, taskboard, user stories and wiki. Web-based and internationalized.”

 

 It’s extremely important that the tool you decide to use with your team is ready for customization via opened API. This feature is a must! Just like a wide range of integrations with other tools. You can find a lot of great integrations with tinyPM:

- You can connect it to Slack in order to stay in touch with every change that was made in your project
- Or link tinyPM with your GitHub: When you push your changes to GitHub, it will forward your commit to tinyPM.
- and much much more! Check out all integrations here.

 

 

“Coming together is a beginning. Keeping together is progress. Working together is success.” H. Ford
Building a team isn’t an easy task. As a matter of fact, as we’ve already agreed – it can be very tough. Nonetheless, it’s worth to put as much attention and effort to constantly improving your teamwork and increase the team spirit. Despite all hurdles and problems that will follow somewhere along the line, just remember that teamwork is the factor that will help you to win the game.

 

3 steps to write good commit messages

Piotr Romanowski

Commit

“If a thing is worth doing, it’s worth doing well” 

 

As you may know tinyPM is integrated with such SCM tools like Github, Beanstalk, Bitbucket and Stash. Thanks to this integration you can group all commits in a logical structure that corresponds to your backlog structure in tinyPM.

This is actually an awesome thing because you can easily access not only the history of particular user story, but also its development history.

And indeed, it’s all about communication. Almost all software projects are collaborative team projects. A well written commit message is critical to communicate the context of change to team members. Moreover, later on you can easily check and understand the context without going back to it again and again. This is how you can save your time and resources.

Now, this is not only developer’s or project manager’s dream about having everything in the right order and place. Let’s stop dreaming – it can all be done properly here and now!
There is only one condition – a whole team needs to be willing to write great commit messages. And now it’s time to show you how to do that.

 

 

Here are 3 rules to follow:

 

1. KISS – Keep It Simple Stupid 
A good commit message should be concise and consistent.

If the change is trivial that where explanation is not required, single line is sufficient enough as a commit message.
It should be written in an imperative style like “fix a typo”:

If applied, this commit will fix the typo.

 

If a commit is more complicated we need to write a subject (in an imperative style) and provide explanation.
Within this explanation, we should focus on describing why this change was made and how it benefitted the project.

It’s very important that a commit should refer to one logical change at a time. What does it mean? It’s not correct to write message like: “fix the filtering bug, the searching bug, and add attachments to the user story”. Here we should create three, separate commits:

fix filtering bug 

fix searching bug

add attachments to user story

 

2. Use three magic questions to provide sufficient context
Peter Hutterer wrote that good commit message should answer three, fundamental questions:

- Why is it necessary?
Concise description of the reason why a commit needs to be done. What does it fix? What feature does it add? How does it improve performance or reliability?

- How does it address the issue?
For trivial patches this part can be omitted. There should be a high-level description of what the approach was.

- What effects does the patch have?
(In addition to the obvious ones, this may include benchmarks, side effects, etc.)

 

These three questions will help you to provide all necessary information and context for future reference.

 

You can easily link commits to tasks or user stories in your tinyPM. Simply include a user story #id in the commit message #512 and the commit will show up on this particular story card:

Add a list of recommended products #512

For more instructions about commit syntax please check tinyPM documentation.

 

 

3. Do not use excuses!

We all know that sticking to the rules can be a pain in the neck. However, this is often necessary in order to achieve certain goals. Our goal is to write great commit messages, therefore, we need to adhere to such rules.

And yes, there will be a lot of excuses like: “but it works”, “we didn’t have time” or “I’m the only one working on this” and a dozen of others. Finding excuses is way easier than being consequent. Therefore, we need to think about it in the big picture – think how many benefits we can get.

Just remember that good programmers can be recognized by their legacy. Good commit history will help others to start work on such projects readily without any problems figuring it all out.

This should become a habit that will constantly benefit a whole team in terms of productivity and efficiency as well as a sense of satisfaction.

 
The last word belongs to Chris Beams: “(…) just think how much time the author is saving fellow and future committers by taking the time to provide this context here and now.”

What happens if you combine and integrate two awesome tools?

Piotr Romanowski

tinypm_slack

Have you heard about Slack?
No? So you need to catch up. Slack is an awesome platform for team communication – “everything in one place, instantly searchable, available wherever you go“.

It’s really great! You can easily improve your team communication by creating open channels, projects and topics that the whole team shares. What do we love most about Slack?
- splendid search feature
- easy way to attach pictures and other files
- beautiful design
- simplicity

It’s just “everything in one place”!

 

To provide you with essential value of your work
We’ve integrated tinyPM with Slack! Now, you can check what happens when two awesome tools work together to bring you everything necessary to perform a great job!

This is one of these tiny things that help you to transform your good team into a great team! Now you can stay up to date with every change that was made in tinyPM. This integration will post updates to a channel in Slack whenever a story or task activity occurs. How cool is that? images

tinyPM_notification_in_Slack

That’s why we’ve decided to integrate our tinyPM with Slack – to provide you with essential value of being always aware of what’s going on with your projects. Getting notified about every change will helps you to manage your team and your projects more efficiently.

 

 

How to connect your tinyPM with Slack?
It’s quite simple and intuitive. You just need to activate Slack in tinyPM’s settings. You’ll need to create and Incoming Webhook in your Slack:

  • Open Slack
  • Click on the dropdown next to your team name and select Configure integrations
  • Select Incoming WebHooks
  • Copy the Webhook URL to your clipboard

 

Once you’ve created Incoming WebHook in Slack:

  • Open your tinyPM
  • Go to “Application Settings”
  • Click on Slack integration
  • Paste WebHook URL

 

That’s it! As simple as that. From here on, working with tinyPM and Slack integration you will save your time, manage your projects way better that before and communicate more efficiently.

 

Tell us about your feelings with regards to tinyPM and Slack integration. We’re looking forward to receiving your feedback.

Always use a proper tool

Piotr Romanowski

hammer
Photo Author: justinbaeder / photo on flickr

 

From Don Reinertsen’s “Managing the Design Factory”

 

There is no need to say how crucial it is to use proper tools in order to achieve specific results. Just like in the above quote, we need to bear in mind that if we use a good – or rather, the best tool, it will “enhance our ability to achieve a certain effect”.

It’s not a rocket science but a very important rule. If you’re running a project you need to find the best tool that will help you manage your projects efficiently. It’s also important that ‘the best tool’ you find should be as simple in use as possible. You don’t want to waste your time to understand how this tool works, do you? Instead, you want to use it here and now!

That’s why we’ve created tinyPM – a simple, intuitive and a smart agile collaboration tool.
Here you can find a sneak peak of some of our great features:

 

Backlog
A place where the vision of your product takes shape. TinyPM not only lets you create your backlog but what is more important, it allows you to groom it. Reordering of user stories with a drag and drop feature, sort and filter them. Quickly tag many stories, change their colors. Edit story details through in-line editable fields.

 

Taskboard
This is a place closest to a white board on your wall. This is where things get done on daily basis. You can shape your flow as you like, starting with three progress statuses we give you. Feel free to add more and take control over your board!
It’s up to you! Move them around, leave comments, assign as many team members as you wish. This is a place where developers rule and we help them seed up their work.

 

User stories
tinyPM gives you more than just a post-it note to write on. Swarm over user story, discuss it, attach details, tag it (if it’s hard to split a product into hierarchical structure, give it more dimensions), use different card colors and feel the power of visual management.

 

Customizable view
Different job may require you to look at at your data differently. When you start your project and plan ahead, things look different than when you are in the middle of your work. We understand that and provide you with customizable view options. Choose between cards and tables, change zoom level to hide or show more details. Switch between 1-column and 2-columns view whenever you need.

 

In order to get all of tinyPM awesome features go to:

http://www.tinypm.com/features

Bye, bye Oldie

Paulina Tomczyk

It already is! The new version of documentation in tinyPM. For those who like to wade through the jungle we left the good old one here. The brand new, more civilized edition, equipped with intuitive menus, which we have prepared using Grails, is available here (www.tinypm.com/docs/guide). We changed the design to a more modern, transparent and consistent color.

Success

Fast but not furious

Previous documentation of tinyPM had a one continuous layout. The new one has a division into sections. It’s easier to navigate as well thanks to the added menu, always displayed on the side. The documentation includes a description of:

tinyPM Docs

From Grails with love

The documentation is generated using the standard mechanism of Grails to create the documentation for the application. Check it out here: grails.org/doc/latest/guide/single.html#docengine. We adapted it to the very great needs of tinyPM to work on our own templates and css styles. The result? A completely different look, and underneath the same syntax wiki for quick and easy creation of documentation.

How do you like it? Are there any gaps, lacks or mistaken attacks? :-)

Today about Iteration big and small

Marcin Niebudek

We have already had User Story as most popular tool. But this is not the end. Today about Iterations: the small and big ones, these that are completed and those that are never stopped.

Yes We Can

Iteration is a period of 1 to 4 weeks. During this time Customer needs to decide what is the most important at this moment. 4 weeks is also called the Sprint but we prefer Iteration as it’s stronger option.

Iteration is not only about programming but also about tests and more. Actually tests are run before the programming phase.

We also have to mention about infinite period. In this case Iteration is one, only User Story has to be completed in some period of time and then disappears. In this place another User Story appears. Customer tells about that User Story and if it’s good we start with the new one.

And what do you think about this?

Hot news for GitHub lovers

Paulina Tomczyk

Finally happened! Over 6 million users & over 14 million repositories of GitHub integrated with tinyPM? It’s more than possible now. Imagine product management integrated with the largest code host on the planet. All in one – from vision to implementation. You absolutely have to check it out!

462550595(1)

Why should you try it out?

Integration with GitHub allows you and your team to link commits in GitHub with user stories in tinyPM. This carries your team through the latest development work and the whole history of commits for each story. When you push your changes to GitHub, it will forward your commit to tinyPM offhand. By including a special text in the commit message you can indicate whether this commit is related to a user story or task in tinyPM.

Stay up to date and tie your commits easily to user stories

To enable GitHub integration with tinyPM just activate tinyPM Service in your GitHub repository:

  • In GitHub open a repo you manage and click on Settings
  • Select Webhooks & Services
  • Click Add service and select tinyPM from the available services
  • Add your URL – copy it from the “Application Settings” page in your tinyPM

github-setup

github-url

 

github-setup_service

 

Linking commits to user stories

Simply include a user story #id in the commit message #512 and the commit will show up on this story card.

Example commit message:

task_1

Linking commits to tasks

To add a reference link to a commit, just include a label like task:123 in the commit message.

Example commit message:

task_3
Move tasks via commit messages

Add a message like completed task:123 and tinyPM will update the task status when you push your commit.

Example commit messages:

task_2

Good day & good luck! :-)

 

Timesheet now available in tinyPM 3.1

Maria Hotloś

We’re very excited to announce that the new timesheet feature is now available in tinyPM 3.1. The timesheet is simple and easy to use. It allows you to log the time spent on tasks and gives you instant access to weekly reports by presenting them in a nice and clean table view. You may check out your tinyPM account right now or read on to learn more.


My timesheet

View and log the time spent on tasks of all of your projects with the new ‘My timesheet’ view.

my timesheet


Navigating your timesheet

Use the arrows to move back and forth through the weeks.

week navigation


Log hours

It’s easy to record how long you spent on a task. Just click the selected cell and change the value instantly. Using <TAB> key you can fill in several cells (days) quickly.

log time


What tasks are contained in the timesheet?

tinyPM knows what tasks you’re working on and displays the appropriate ones. Additionally, the cells are marked with color on days that you’ve been working on a given task.

What about the team?

For an overview of your team activity, just click the ‘Team’ button. You will see a list of people you share the projects with and their summary of hours displayed weekly.

team


Quick summary

In the sidebar, there is a summary of the current and the previous month – total hours by project and options to export them.

sidebar


CSV Export

For each project you can download a CSV file, which contains all hours entered by all users during the month. This file you may easily open in your ‘office’ application and convert into your favorite report.

csv


PDF Report

You can also download a ready to print report in a PDF format.

pdf


We hope this timesheet makes time tracking easy and fast for you. We’d like to know what you think, as we plan to continue improving it, so the feedback and new ideas are highly welcome.